-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ambiguity between sigils and macro fresh variables #14782
Comments
I understand the fresh variable index syntax can be considered somewhat like syntax sugar. Maybe we could remove the syntax sugar entirely and use The fresh variable syntax also allows multiple index values ( |
Simple interpolation can be problematic if the index is not something that is valid as part of an identifier (e.g. negative numbers, defs). |
Another, simpler idea: We keep the fresh variable index syntax as is, but require (or recommend) to put a special character between the name and the opening curly brace. This character should never be used in the sigial of a percent literal. For example an underscore. So |
You mean in docs, or as a warning? |
Incrementally reinforcing: documentation, formatter, warning, syntax error |
Why not simply add a warning to never use single-letter "fresh variable" identifiers? It's never required to have a particular name for them, and it affects literally nothing. I'm saying this especially in light of #14782 (comment) |
Yeah, might be overthinking it. That's all assuming, we'll only ever use single letters as indicator for percent literals. We don't have a use case for multi-letters yet, and maybe there is none. So this might be fine. |
Crystal supports 6 sigils which modify the meaning of string literals. Curly braces may be used instead of the usual double quotation marks for those strings:
The same syntax is used for fresh variables inside macros:
It is a syntax error here to use a fresh variable name that coincides with one of the sigils, because the sigil has precedence and assignment to a string literal is never allowed. This is problematic since adding any new sigil to the language, e.g.
%b
for #2886, immediately introduces a breaking change by making those macros no longer valid.I believe the language should be more future-proof here, unless we can say for sure that new sigils must not be introduced.
The text was updated successfully, but these errors were encountered: