-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Svelte 5: unable to name a variable with the "same name" as a rune #12328
Comments
It's not really about runes but stores — if you declare a variable |
@7nik yes indeed, makes sense! I'm quite new to using runes, so I kind of forgot about stores as I was focused on playing around with runes, but yeah, that makes sense. In my opinion, there are two possible solutions here:
|
Both are not easily feasible:
Afaik because of those reasons, runes with the same names as variables are automatically disabled |
The first solution is impossible. Static analysis cannot cover all possible cases. |
What does that mean?
That's true... What's the best way around it then? A simply better warning message? |
Svelte 4 / non-rune mode. |
Weird, it was in Svelte 5 when I posted it. Fixed. |
There is already a warning for this problem, as you can see in the REPL. |
The current warning implies overriding runes is allowed, not that such a thing is not possible and the variable should be renamed |
I didn't interpret the warning to imply that you could override runes, more that the naming of your variable conflicts with a rune in scope, so rather than acting like a rune, it will act like a store. So renaming the variable avoids it from acting like a store. |
This works as expected. We decided to give stores precedence over runes in this situation. |
It looks like this was a duplicate of #12218. I don't know which one we want to keep. |
That issue sounds different to me - I understand it as a request to not reserve the $ prefix |
@Conduitry I agree with Simon: my request was to better handle/warn about using "rune-named" variables, whereas the other issue is about allowing However, both issues would be solved by disabling some/all impacted runes when a conflicting name is found. Out of curiosity, how did you come up with this idea of prefixing runes with |
Describe the bug
When naming a variable with the same name as a rune, without the
$
, likestate
orderived
or others, the compiler considers them as the same, thus leading to errors likeCannot access 'state' before initialization
or errors relating to rune re-affectation.Even if it's not a bug, runes re-affectation should be prohibited.
Reproduction
https://svelte-5-preview.vercel.app/#H4sIAAAAAAAACj2N0QqDMAxFfyUEH9wQHHsaVQf7jrkH10ZWqG1pU2GI_z46N99yT3JPFhy1oYjivqAdJkKBN--xQn77HOJMhgkrjC4FmUm7IeE8a2cjhGQpQn3tbW_bKIP2nGc2xCBdsgwdFJEHpvJ0aPJGOhsZvgg6uGS2U0VBz6Sggx5fZIzrsfnblEtPkyvF76rc_Ec4Z3Fb79-xwskpPWpSKDgkWh_rB8K78zLqAAAA
Logs
No response
System Info
Severity
annoyance
The text was updated successfully, but these errors were encountered: