Symbol VS string for the `fantasy-land` property

[rpominov]

This was discussed when we made methods on prototype prefixed. And overall impression was that symbols don't add any value compared to just unique enough strings. See fantasyland/fantasy-land#146

I think we should revisit this. Although I personally still don't see any advantages of symbols, it might be the case that we just missing something.

[lin7sh]

I'm up for Symbol. I don't know the implementation detail of Symbol, but using Symbol conforms the the use case for FL, for me obj[fl.map] is very like obj[Symbol.iterator] which is the convention for ES6. So besides of the potential performance advantage of using Symbol(I don't really know if there is), it feels nature for the normal JS programmer(like me) who knows the convention to use Symbol.

[davidchambers]

I've yet to have anyone explain to me a single benefit of symbols given that they are defined in a global registry and thus share a namespace (just as strings do, really).

[rpominov]

Ok to play a devil's advocate a bit, here a couple minor benefits of Symbols:

• Even though they also live in a shared global namespace, this namespace is much less occupied, so in this namespace chance to have a name clash is smaller.
• As @mko-io pointed out, Symbols are more familiar to people for such kind of things. They seem to be more idiomatic. So maybe to use Symbols would be more mainstream way, and we want to be mainstream.
• Also Symbol properties are not enumerable by default. But not sure if this good, bad, or doesn't matter.

[lin7sh]

As far as know, Nodejs is using Symbol for protocol alike thing in the internal module. So more developer would adapt to the idiom for the usage