Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

rcxdude
Copy link
Contributor

@rcxdude rcxdude commented Feb 16, 2014

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

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.
@alexcrichton
Copy link
Member

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");
Copy link
Member

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?

Copy link
Contributor Author

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.

@huonw
Copy link
Member

huonw commented Feb 16, 2014

👍 having some way to exactly input floating point is useful.

@emberian
Copy link
Member

emberian commented Mar 2, 2014

The feature seems useful but does it need to be part of the language? Can we get away with a syntax extension here?

@rcxdude
Copy link
Contributor Author

rcxdude commented Mar 2, 2014

Hmmm, I guess a syntax extension could work. It would involve returning an AST object which couldn't be generated normally.

@emberian
Copy link
Member

emberian commented Mar 2, 2014

Any time you have a literal it's just an expression, which macros can
always replace. But, are there problems with the normal float literals that
this solves, that a syntax extension wouldn't be able to paper over?

On Sun, Mar 2, 2014 at 10:04 AM, Douglas Young [email protected]:

Hmmm, I guess a syntax extension could work. It would involve returning an
AST object which couldn't be generated normally.


Reply to this email directly or view it on GitHubhttps://github.com//pull/12323#issuecomment-36456237
.

http://octayn.net/

@alexcrichton
Copy link
Member

Closing in favor of #12652, I believe that is the route that we will be taking before taking this route.

bors added a commit that referenced this pull request Mar 11, 2014
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?)
bors added a commit that referenced this pull request Mar 11, 2014
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?)
flip1995 pushed a commit to flip1995/rust that referenced this pull request Feb 26, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants