-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Reserve more numeric types. #907
Conversation
Previous discussion: #138 |
What is this protecting against? That is, what's a program that will stop compiling if we don't reserve them? It seems to me (and the filer of the original RFC) that shadowing should mean things work fine. |
As mentioned in the RFC:
|
|
||
# Detailed design | ||
|
||
Reserve the following type names: `fN`, `uN`, `iN` for `N` a multiple of 8. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What limit? Or just to, say, 232?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whatever the parser can handle.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The parser can handle arbitrarily large numbers: congruence mod 8 can be determined using only the last 3 digits of a number represented in base 10, meaning string handling works fine, and hence i1234567891234567891234567891234567800
could be checked to be "valid" under that rule.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason to limit ourselves to numbers that are a multiple of 8? Why not just reserve them for all numbers?
Why take only multiples of 8 for |
That's a pretty annoying shadowing restriction right there, though it does avoid exposing the resolve bugs around such things... |
@cmr |
👎 to this RFC as written, it's a really large hammer and only makes sense if we had arbitrarily sized primitives (like The only approach I know of and I consider (more or less) "correct" would be the one mentioned in the comment linked by @petrochenkov above. That would protect against breakage by explicitly having all existing built-in types part of That said, I almost forgot about it, and it requires associated constants to be done backwards-compatibly (or as close as we can get to that). |
We should fix the bug itself, not to shadow it with strange behavior. |
Thanks for the RFC! After some discussion, however, we don't think that this is the strategy that we would want to take. It is arguably a resolve bug which prevents shadowing primitives and we can consider it a requirement that adding a type like |
Rendered