Pre-RFC: Hex float literals


C allows hex float literals (of the form 0xffffff.fp0). These literals, have some uses – for example, they are guaranteed to map to an exact, obvious bit pattern.

However, Rust does not allow such literals. It has decent reasons for doing so (see issue#1433). In particular, they vastly complicate parsing: there is an ambiguity between a hex float literal and a field and/or method off of an integer. This is not, strictly speaking, ambiguous: integers have no fields, and trying to call an integer as a function will be rejected by the type-checker. So one can disambiguate 0xFFFFFFF.Fp3 as being a float if and only if it is not followed by an open parentheses. That, however, is very clumsy, and we really really don’t want to need to do that in the lexer.

A much simpler approach 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.

Finally, I propose that the float parsing functions in the stdlib be modified to accept all forms accepted by strtod. The lexer can reject the ones that are invalid in Rust source trivially.


It also wouldn’t be unreasonable, if fields for integers are added later, to require they be used like (123).field. Python e.g. does this.


The hexf crate implements a procedural macro such that one can write hexf!("0xFF.Fp1") and have it evaluated at compile time. It also includes run-time parsing functions. While this is obviously a bit less nice than having literals in the language, it does raise the bar for changing the language. Personally, while I would have liked hex float support in the language, I believe the crate is good enough that it’s not worthwhile to try and change the language.


True, but procedural macros are likely to be unstable for quite a while, whereas this is such a trivial change in the lexer that it can be stabilized very quickly – I suggest making waiting at most one release.

The only difficulty is that the lexer now must backtrack, but that should not be too difficult.


Sorry, I should have been more specific. The crate uses macros 1.1, not old-style procedural macros, so it works on stable (since several releases ago).