-
Notifications
You must be signed in to change notification settings - Fork 1.7k
symbols should be canonicalized #15455
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
Comments
Added Area-Library label. |
This comment was originally written by @mhausner Aren't they canonicalized implicitly because they are allocated with const Symbol(...)? |
identical(const Symbol('foo'), new Symbol('foo')) ? |
This is only a problem with "new Symbol(x)" where x is not a compile time constant. However, for "new Symbol(x)" where x is a dynamic value, it would require caching all created symbols, which is a potential memory leak. So, we might need to keep the symbols alive forever. That's something we have avoided in other cases, where we did not want to force canonicalization because of the risk of a memory leak. We do warn that using "new Symbol" can cause your program to bloat, but I don't think we should do it blindly. Maybe we could just canonicalize symbols that occur as constants in the program already, and create other symbols dynamically as a subclass that overrides operator==. That way, you will always get identical(#a, new Symbol("a")) , but not necessarily identical(new Symbol("b"), new Symbol("b")) if #b does not occur as a constant. That would allow using the constants as map keys and switch cases, and require retaining anything but the constants that are already there. It needs to work for private symbols too, so MirrorSystem.getSymbol needs to be in on the trick. It should also return something that has the same class as for public symbols, or you can't use them in a switch, which is an artificial problem. This is all about the library Symbol class(es). It should not affect user classes implementing Symbol (which are allowed). |
I'll change the documentation if the implementations will promise to implement the canonicalization - that's the hard part, after all. cc @floitschG. |
Symbols allocated with "new Symbol('k')" should not be required to be canonicalized. |
I believe the current plan is to special-case symbols in switch cases at the spec level (like we do for String and int). cc @gbracha. |
Symbols should be canonicalized to ensure that it is crystal clear they can be used as map keys.
The text was updated successfully, but these errors were encountered: