Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Type System
-
Labels:None
-
Number of attachments :
Description
In order to protect from problems when converting or assigning value types, the following guidelines should be used at compile time and during the runtime (for dynamic assignments):
t as double = 3 # No error, implicit conversion from int to double does not cause loss of resolution
t as int = 3.0 # Error: no implicit conversion from double to int because that would cause a loss of resolution
t as long = 3
u as int = t # Error: no implicit conversion from long to int; loss of resolution
t as int = cast(int, 3.0) #No error, explicit conversion completes; programmer understands loss of resolution
t as long = 3
u as int = cast(int, t) # No error, explicit conversion completes; programmer understands loss of resolution
These conversion rules for the built-in types follow the conventions of C#
for the implicit conversion, the one-way order of implicit conversion goes:
byte -> int -> long -> single -> double -> decimal
Attachments
Issue Links
| This issue relates to: | ||||
| BOO-1115 | Strict mode |
|
|
|
b as byte = 255 //works, like in C#
b as byte = 256 //fails at compile time, like C#
i as int = 3.0 //works, since 3 is within range of valid int values
Change TypeSystemServices.GetPromotedNumberType if you want things to behave more or less like C# (I didn't touch that method). But everything looks fine to me the way it is.
People will have to be told about this change, since it is more strict than before, but it is easy to add a cast if for example you want to convert a decimal to an integer (before you didn't need to).