RFC to restrict placing an identifier after a literal. #463
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
See #329 for an old, restricted version of this. |
| - Should it be the parser or the tokenizer rejecting invalid suffixes? | ||
| This is effectively asking if it is legal for syntax extensions to | ||
| be passed the raw literals? That is, can a `foo` procedural syntax | ||
| extension accept and handle literals like `foo!(1u2)`? |
There was a problem hiding this comment.
parser. We get maximum flexibility that way, for minimum overhead
|
+1 seems like a less hacky and more flexible way to implement our literals syntax |
|
+1 |
|
This was discussed at this week's meeting and we will accept, however, we will not block 1.0 on it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Include identifiers immediately after literals in the literal token to allow future expansion, e.g. "foo"bar and a 1baz are considered whole (but semantically invalid) tokens, rather than two separate tokens "foo", bar and 1, baz respectively. This allows future expansion of handling literals without risking breaking (macro) code.