Open richard-uk1 opened 4 years ago
To go even further, if the lexer could not find an exponent after the e
, it could return LitFloat { suffix: "e", .. }
although personally I think this could produce confusing diagnostics.
I've found further inconsistencies here. Numbers like 2f
will also fail the lexer, presumably because it looks for f32
or f64
.
I think I would now argue that the lexer should accept all combinations of letters and numbers coming after the first number. This way, any sequence of numbers and letters is a valid token: an Ident
if it starts with a letter and a numeric literal if it starts with a number. The parser could ensure the same diagnostics as currently.
Doing this would enable, for example, someone to write a procedural macro that turned 12floz
into Weight::FluidOunces(12.0)
, or accept any html hex color (3fc25a
, for example).
Currently, the lexer will reject tokens like
1.0etest
expecting an exponent after thee
. It could alternatively accept this token asLitFloat { value: 1.0, suffix: "etest" }
. This would mean that proc macros could use suffixes that start with ane
(although not the suffixe
itself of course).