symbols should be canonicalized

[peter-ahe-google]

Symbols should be canonicalized to ensure that it is crystal clear they can be used as map keys.

[peter-ahe-google]

Added Area-Library label.

[DartBot]

This comment was originally written by @mhausner

---

Aren't they canonicalized implicitly because they are allocated with const Symbol(...)?

[rmacnak-google]

identical(const Symbol('foo'), new Symbol('foo')) ?

[lrhn]

This is only a problem with "new Symbol(x)" where x is not a compile time constant.
If x is a compile time constant, it is easily replacable by "const Symbol(x)" at the source level (and the compilers can do that).

However, for "new Symbol(x)" where x is a dynamic value, it would require caching all created symbols, which is a potential memory leak.
We could make the cache weak, so that when there is no references left to the symbol, we collect it, but that would still risk exposing a new hash code. Example:
 var s = someStringExpression;
 var s1 = new Symbol(s).hashCode;
 // do something that causes a GC
 var s2 = new Symbol(s).hashCode;
 Expect.equals(s1, s2); // shouldn't be able to fail, but can.

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).

[lrhn]

I'll change the documentation if the implementations will promise to implement the canonicalization - that's the hard part, after all.

---

cc @floitschG.
cc @iposva-google.

[iposva-google]

Symbols allocated with "new Symbol('k')" should not be required to be canonicalized.

[lrhn]

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.
Added NotPlanned label.