RFC to lex binary and octal literals more eagerly. #879
Conversation
|
The part that still strikes me as awkward is that suffixes have an invisible constraint (as in, not obvious at the point where the |
|
While that is a reasonable point (a user-defined suffix must not start with a valid hex char to be usable with hexidecimal literals), I'm not sure it's relevant to this RFC in particular. That is, even if we had no suffixes, I would still be in favour of this more eager lexing. |
|
If we had no suffixes, the lexing should be even more eager ( |
|
What about |
|
@Ericson2314 good point! In this case, I think we automatically effectively get that grammar with this change (well, the ability to switch to it backwards compatibly), since e.g. |
|
There's probably an obvious reason this won't work, but what about requiring |
|
@aidancully Interesting! In Haskell type ascription has very low precedence, but this allows a maximally high precedence type ascription to be introduced replacing the lexing suffixes trick backwards compatibly. |
|
@aidancully @Ericson2314, +1, this is a neat way to avoid duplicating features once "full" type ascriptions land. |
RFC to lex binary and octal literals more eagerly.
|
Accepted! I'm not going to make a tracking issue, since @huonw already has a patch prepared. |
Previously 0b12 was considered two tokens, 0b1 and 2, as 2 isn't a valid base 2 digit. This patch changes that to collapse them into one (and makes `0b12` etc. an error: 2 isn't a valid base 2 digit). This may break some macro invocations of macros with `tt` (or syntax extensions) that rely on adjacent digits being separate tokens and hence is a [breaking-change] The fix is to separate the tokens, e.g. `0b12` -> `0b1 2`. cc rust-lang/rfcs#879
Rendered.