-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Add support for non-decimal floating point literals. #12323
Conversation
Issue rust-lang#1433. The syntax chosen was requiring an 0b, 0x, or 0o after the dot. If the literal is hexadecimal, an exponent is required.
This is a language change which needs to be discussed. I'm mostly ok with this, although requiring the radix again after the dot seems odd to me. |
//The ability to switch base, while conceivably useful, is much more | ||
//likely to be triggered by accident. | ||
fatal_span(rdr, start_bpos, rdr.last_pos.get(), | ||
~"float literals must have consistent base before and after decimal point"); |
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.
If they have to be equal, why not just not require the second one? so 0xab.cdef
and 0b101.0101
etc. would all be valid?
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.
This was mentioned in the issue. Because 10.method() is valid, there needs to be a way to disambiguate, ideally without requiring long lookahead. For the binary and octal cases it could be dropped though.
👍 having some way to exactly input floating point is useful. |
The feature seems useful but does it need to be part of the language? Can we get away with a syntax extension here? |
Hmmm, I guess a syntax extension could work. It would involve returning an AST object which couldn't be generated normally. |
Any time you have a literal it's just an expression, which macros can On Sun, Mar 2, 2014 at 10:04 AM, Douglas Young notifications@github.comwrote:
|
Closing in favor of #12652, I believe that is the route that we will be taking before taking this route. |
Closes #1433. Implemented after suggestion by @cmr in #12323 This is slightly less flexible than the implementation in #12323 (binary and octal floats aren't supported, nor are underscores in the literal), but is cleaner in that it doesn't modify the core grammar, or require odd syntax for the number itself. The missing features could be added back with relatively little effort (the main awkwardness is parsing the string. Is there a good approach for this in the stdlib currently?)
Closes #1433. Implemented after suggestion by @cmr in #12323 This is slightly less flexible than the implementation in #12323 (binary and octal floats aren't supported, nor are underscores in the literal), but is cleaner in that it doesn't modify the core grammar, or require odd syntax for the number itself. The missing features could be added back with relatively little effort (the main awkwardness is parsing the string. Is there a good approach for this in the stdlib currently?)
Fix: no_effect_underscore_binding fires on ignored parameters of async fns Fixes rust-lang#12279 changelog: Fix [`no_effect_underscore_binding`]) The warning is no longer displayed when an underscore is given in the parameter name of an asynchronous function.
Issue #1433. The syntax chosen was requiring an 0b, 0x, or 0o after the dot.
If the literal is hexadecimal, an exponent is required.
Tests seem to pass except 'make check' does not complete for me because of #12322