-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Added octal literal support. #10243
Added octal literal support. #10243
Conversation
Thanks! Let's discuss this change to the language in a weekly meeting before merging. |
I experimented some time back with a couple of ways of doing file modes without needing to resort to comparatively meaningless numbers; for example, defining a macro which could take every possible combination and turn it into a number (that revealed severe performance problems on macros with many thousands of rules... who'd 'a thunked it? If you were doing it seriously, you'd do it as an ultra-fast syntax extension, not as a ridiculously expensive macro that adds three minutes to compile time whether used or not) or constants for every possible combination, like Still, the principle is right: often defining constants will be sufficient for your purposes. A quick look at the Apollo Guidance Computer suggests it uses octal memory addresses, which would suggest that constants are slightly infeasible and having octal literals would indeed be of value for that case (but you could theoretically define lots of constants or use a macro, like I did!). Still, octal is used by surprisingly few things. Potentially of more use would be making it possible to have arbitrary base literals. As a demo with no more than twenty-seven seconds' thought put into the syntax, I can imagine something like |
chris-morgan+1 Arbitrary base literals would be really cool. J has them (with the exact same syntax you proposed), and bash and Ada have them with a '#' instead of 'b'. |
I like the idea of arbitrary base literals. In thinking about the syntax, it makes a problem for the suffixes. Past a certain base, u32, u16, etc are perfectly valid numbers. Ada wraps the number in #, which is definitely one way to fix it. |
This will also need some positive tests, i.e. checking |
+1 for arbitrary base literals. Though having built in hex, binary, and octal is nice. |
I've been ambivalent about this for a while. I lean 👎 but octal is extremely useful in the extremely few cases it's useful in. |
Let's add octal literals per this pull request and defer the question of arbitrary bases to later. |
I'm stopping the build for now, the code looks fine but I agree with @huonw that this requires more tests. Having negative tests is a good thing, but we should also have some positive tests (to make sure they're parsed correctly). |
Associated with Issue #6563. Useful for Apollo Guidance Computer simulation, Unix file system permissions, and maybe one or two other things.
- Cause `0` to be considered a valid integer literal (it is). - Add octal literals (missed from rust-lang#10243). I have *not* modified doc/po/rust.md.pot or doc/po/ja/rust.md.po at all; they already seem to be out of date so it's easier to ignore them for myself. I can update them if desired, of course.
…eference-manaul, r=cmr - Cause `0` to be considered a valid integer literal (it is). - Add octal literals (missed from #10243). I have *not* modified doc/po/rust.md.pot or doc/po/ja/rust.md.po at all; they already seem to be out of date so it's easier to ignore them for myself. I can update them if desired, of course.
Where did this code go in the latest |
…ng_sub_expression, r=xFrednet Diverging subexpression lint should not fire on todo!() As per rust-lang#10243 it is not that helpful to point out that a subexpression diverges, so do not fire on todo changelog: [`diverging_sub_expression`]: do not trigger on todo
Associated with Issue #6563.
Useful for Apollo Guidance Computer simulation, Unix file system permissions, and maybe one or two other things.