Hex float literals (alternative syntax)

language design
1

there have been a lot of threads about hex float literals. we'd like to suggest a slightly different syntax for them:

0f32x10FFFF.0

this is fully unambiguous and can be quite trivially parsed. same goes for 0f64x.... thoughts?

2

This does indeed not cause grammatical issues, as this currently is an error at the lexical stage[1], as this is currently interpreted as an float[2] literal with the suffix f32x10FFFF, which is not an allowed suffix.

That said: we already recognize (and emit a lexer-stage error for) "regular" hexadecimal floating point literals,

macro_rules! m {
    ($l:literal) => {};
}

m!{0x10FF.0p7F}

error: hexadecimal float literal is not supported
 --> src/lib.rs:5:4
  |
5 | m!{0x10FF.0p7F}
  |    ^^^^^^^^

error: invalid suffix `p7F` for float literal
 --> src/lib.rs:5:4
  |
5 | m!{0x10FF.0p7F}
  |    ^^^^^^^^^^^ invalid suffix `p7F`
  |
  = help: valid suffixes are `f32` and `f64`

so I see no reason that if we did want to support hexadecimal floating point literals, that we wouldn't just support the ones we already recognize and stop emitting an error.

Sure, it might be problematic to end a floating point literal with f32 and have that be part of the number, not a type suffix, but that can reasonably be linted against. If the proposal is just to put the type suffix early.... that's very not clear from the proposal, which is proposing "new, alternative syntax."

[1] meaning, importantly, a macro cannot recognize and consume the syntax, as it crates an unsuppressible error earlier.

[2] this is interesting... I don't know why the compiler is interpreting this as a float literal rather than an integer literal, as the suffix starts after just an integer. It's probably because it starts with f and it wants to suggest f32 for e.g. 0f, not integer suffixes.

1 Like
3

Ideally letting the language convert hex for you is better than manually converting hex and then pasting that into the language, especially if the hex is a magic number that makes more sense as a hex (e.g. 0x10FFFF is the unicode limit, and sometimes you want to test if it fits in a float and ofc rust is the appropriate language for testing whether an arbitrary number fits in a float).

1 Like
4

interestingly enough, 0x10FFFF is also easily recognizable in decimal: 1114111

1 Like
5

anyway, it is only an alternative snytax for existing and future proposals related to hex float literals. in case anyone wants to try to push those through again.

6

Prior discussion: issue 1306, issue 1433, earlier pre-RFC.

All else being equal, it seems to me the smallest possible change from the C syntax is desirable, and it looks like the earlier pre-RFC proposes just that:

[the problem with the C syntax 0xFF.Fp1] is there is an ambiguity between a hex float literal and a field and/or method off of an integer.
...
[A straightforward solution] is to require the + or - sign in the exponent. 0xFF.Fp+1 is completely unambiguous: since integers have no fields, it will always be rejected by the typechecker, regardless of its context. As such, it is 100% backwards compatible (except to the writers of syntax extensions) to make 0xFF.Fp-1 a single lexeme.

I'm tempted to just send a PR.

2 Likes
7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.