-
Notifications
You must be signed in to change notification settings - Fork 10
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
Get non-int64/float64 numeric constants working efficiently #215
Comments
Thinking about it with the new syntax, if I make built-in functions to work with the |
How to handle situations like |
For the new setup, I think the I am hesitant to have a "spooky action at a distance" with this, so I'm still thinking of the resolution happening at the end of the statement, though, and the resolution being based on the "last" possible Well, phooey, or rather F-U-I. Floats, Unsigned Ints, Ints. That should be the order specified, and then because the majority of my APIs assume So The difference, though, is that we can use the constant size and polarity to automatically eliminate types from this list. Eg, If there's no explicit type associated with the value, it'll pick the last one in that list, which will usually be |
It is currently actually impossible to define numeric constants other than
int64
andfloat64
. First-time usage in another size goes through a conversion function to load the global constant data in a smaller size.Perhaps steal Rust's
0i8
style postfix annotation to declare them, or have the compiler detect0.toInt8()
as a unit and replace with the smaller constant type.The text was updated successfully, but these errors were encountered: