You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has been an open question in the proposal. With #78 I'm leaning toward no implicit type conversion at all when using types. The issue is number literals I think from #27 .
First though, the conversions I think we can get rid of easily would be int<N> and uint<N> implicit conversions. So int8 to int16 conversions would need to be explicit. And all floating point conversions. Number appears to be the primary issue.
What I want is the following:
functionf(a:uint8){}f(1);// 1 is a literal and would convert. It would never be interpreted as a Number here
The issue is propagating types to literals. Is this something implementers can handle easily?
functionf(a:bigint){}f(2**53+1);// This would find the signature and the the literals would be treated as bigint
let a:int8=1;// f(2**53 + a); // TypeError: a is int8, expected bigintf(2**53+bigint(a));
WIP: Include some more complex examples of how this propagation could work.
Possible issues is the following is already valid syntax:
The big picture here is that literal suffixes in typed code is completely unnecessary if the engine can attach a type to the literal expression. In dynamic code like the bigint constructor it wouldn't be able to. Unless... a breaking change was allowed and the bigint constructor was changed to bigint(value:bigint) and values over MAX_SAFE_INTEGER would then be handled if the whole expression tree can be treated as bigint. If even one variable is dynamic then it wouldn't.
The question then is anyone in production code using literal Numbers or expressions over MAX_SAFE_INTEGER where they depend on the output as is. My guess is no.
The text was updated successfully, but these errors were encountered:
This has been an open question in the proposal. With #78 I'm leaning toward no implicit type conversion at all when using types. The issue is
number
literals I think from #27 .First though, the conversions I think we can get rid of easily would be
int<N>
anduint<N>
implicit conversions. Soint8
toint16
conversions would need to be explicit. And all floating point conversions. Number appears to be the primary issue.What I want is the following:
The issue is propagating types to literals. Is this something implementers can handle easily?
WIP: Include some more complex examples of how this propagation could work.
Possible issues is the following is already valid syntax:
The big picture here is that literal suffixes in typed code is completely unnecessary if the engine can attach a type to the literal expression. In dynamic code like the bigint constructor it wouldn't be able to. Unless... a breaking change was allowed and the bigint constructor was changed to bigint(value:bigint) and values over MAX_SAFE_INTEGER would then be handled if the whole expression tree can be treated as bigint. If even one variable is dynamic then it wouldn't.
The question then is anyone in production code using literal Numbers or expressions over MAX_SAFE_INTEGER where they depend on the output as is. My guess is no.
The text was updated successfully, but these errors were encountered: