You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is intended behavior, since we always prioritize matches by the amount of non-parametrized tokens.
[f __ ] wins versus [ __ ] since there's an extra non-parametrized f, and then we naturally only continue the resolution process with the winning match, which is parsed as [f oo] and gets us the symbol error.
Do you have a practical use-case in mind where your behavior would be more appropriate? Otherwise, I think it'd be fine if we leave the current behavior as is.
Sometimes when I write code I make a function or variable with a name that starts with r.
My register pattern is r{i:uZ} (I would think I'm not the only one with this pattern).
This makes it so I have to either surround the function/variable name in parenthesis any time I want to access it, or change the name, both of which are somewhat inconvenient.
This is something I would otherwise usually expect to work, so it's slightly annoying when it doesn't.
Yeah, that does sound pretty useful. Perhaps I'll have to rethink this behavior, but I'm unsure of its consequences at this point. Let me investigate it further!
The text was updated successfully, but these errors were encountered: