Description
I'd like to outline some of the thoughts the team has had about supporting custom ES6 symbols. This is focused on the proposals we have come up with, as well as the challenges associated with them.
The motivation is something like this:
var s = Symbol('hello');
var obj = {
[s]: ""
};
obj[s]; // gives type stringWe have had two genres of proposal here, the entity approach and the type approach.
- Entity approach: Use the compiler's entities as an approximation for the symbol value. In the above example, we would say that the variable
sis the entity that the property key[s]represents. Any key referring tosis the same key, and any other way of referring to the value ofSymbol('hello')is different. - Type approach: Creating a symbol manufactures a type that uniquely represents that symbol value. This would involve introducing a new kind of type constructor. It is potentially far more complex than the entity approach, but in principle it would be more accurate.
There are 4 general challenges with these approaches:
- Symbol aliasing: If you have two variables pointing at the same symbol, you want them to be the same. This is a drawback for the entity approach, but the type approach gets this right.
- Symbol reassignment: If you have one variable that gets assigned two different symbols at different times, you want them to be different. This is a drawback for both approaches.
- Solidifying symbol types: If there is a way to specify that something manufactures a new symbol type, there must also be a mechanism for what happens when the symbol gets assigned to something (solidified). Drawback for the type approach.
- The compiler is architected so that the properties of a type must be determined before analyzing relationships among types. With symbols, figuring out what properties a type has might require analyzing complex relationships among types. This can lead to circularities. This is a drawback for both approaches, but is more severe for the type approach, and the severity tends to increase the more general the feature support is.
Issues 1, 2, and 3 are really just specific cases of a more general problem. Namely, there is no 1-to-1 correspondence between static entities in the code (declarations, expressions) and runtime values. And because symbol identity is based on runtime values, there needs to be a 1-to-1 correspondence with static entities.
I think the best antidote for these issues is to limit the support for symbol properties to situations where we know there is a 1-to-1 correspondence between values and static entities. There are two general approaches we can explore, which share this 1-to-1 philosophy. They both use the entity approach mentioned above as a base:
- Support symbols exactly as a user would write them in ES6. This involves identifying usages where this 1-to-1 correspondence would hold, and only supporting symbols in those contexts. For instance, we might give special preference to const declarations, or disallow using symbols inside a loop or across a function boundary.
- Add TypeScript syntax (perhaps a new kind of declaration), for which we enforce/ensure that the correspondence is 1-to-1, and recommend that users use symbols in the way prescribed by TypeScript with these new forms.
Obviously, neither of these are complete proposals, but this is intended to start a discussion directed at finding a solution that is both feasible and would satisfy users' needs.