-
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
RFC for removing integer inference fallback #115
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,75 @@ | ||
- Start Date: 2014-06-11 | ||
- RFC PR #: (leave this empty) | ||
- Rust Issue #: 6023 | ||
|
||
# Summary | ||
|
||
Currently we use inference to find the current type of | ||
otherwise-unannotated integer literals, and when that fails the type | ||
defaults to `int`. This is often felt to be potentially error-prone | ||
behavior. | ||
|
||
This proposal removes the integer inference fallback and strengthens | ||
the types required for several language features that interact with | ||
integer inference. | ||
|
||
# Motivation | ||
|
||
With the integer fallback, small changes to code can change the | ||
inferred type in unexpected ways. It's not clear how big a problem | ||
this is, but previous experiments[1] indicate that removing | ||
the fallback has a relatively small impact on existing code, | ||
so it's reasonable to back off of this feature in favor of more | ||
strict typing. | ||
|
||
See also https://github.com/mozilla/rust/issues/6023. | ||
|
||
[1]: https://gist.github.com/nikomatsakis/11179747 | ||
|
||
# Detailed design | ||
|
||
The primary change here is that, when integer type inference fails, | ||
the compiler will emit an error instead of assigning the value the | ||
type `int`. | ||
|
||
This change alone will cause a fair bit of existing code to be | ||
unable to type check because of lack of constraints. To add more | ||
constraints and increase likelihood of unification, we 'tighten' | ||
up what kinds of integers are required in some situations: | ||
|
||
* Array repeat counts must be uint (`[expr, .. count]`) | ||
* << and >> require uint when shifting integral types | ||
|
||
Finally, inference for `as` will be modified to track the types | ||
a value is being cast *to* for cases where the value being cast | ||
is unconstrained, like `0 as u8`. | ||
|
||
Treatment of enum discriminants will need to change: | ||
|
||
``` | ||
enum Color { Red = 0, Green = 1, Blue = 2 } | ||
``` | ||
|
||
Currently, an unsuffixed integer defaults to `int`. Instead, we will | ||
only require enum descriminants primitive integers of unspecified | ||
type; assigning an integer to an enum will behave as if casting from | ||
from the type of the integer to an unsigned integer with the size of | ||
the enum discriminant. | ||
|
||
# Drawbacks | ||
|
||
This will force users to type hint somewhat more often. In particular, | ||
ranges of unsigned ints may need to be type-hinted: | ||
|
||
``` | ||
for _ in range(0u, 10) { } | ||
``` | ||
|
||
# Alternatives | ||
|
||
Do none of this. | ||
|
||
# Unresolved questions | ||
|
||
* If we're putting new restrictions on shift operators, should we | ||
change the traits, or just make the primitives special? |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Perhaps default type parameters could be dual-purposed to provide a fallback type for this case (see rust-lang/rust#13702). I.e. the signature of range would become:
although it wasn't clear to me if the original issue was motivated by this very function defaulting to int too often.