Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove implicit type conversions for value types. #79

Open
sirisian opened this issue Dec 6, 2022 · 1 comment
Open

Remove implicit type conversions for value types. #79

sirisian opened this issue Dec 6, 2022 · 1 comment

Comments

@sirisian
Copy link
Owner

sirisian commented Dec 6, 2022

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:

function f(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?

function f(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 bigint
f(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:

BigInt(999999999999999999999999999999999999999999)

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.

@sirisian
Copy link
Owner Author

See this which resolved a few of these concerns: #27 (comment)

Removing implicit type conversions I still believe is useful to protect against errors. Will keep this open as I think more about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant