You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm having trouble seeing what could be addressed in this proposal. Records and Tuples satisfy some of the uses of CompositeKey, but CompositeKey could point to objects, so you'd need some additional thing (such as Symbols as WeakMap keys) to build something analogous. So, this might be considered to subsume that, but I don't see what we'd change in either proposal.
As @littledan said, there does not appear to be anything that the R&T proposal will need to do in the context of the separate composite keys proposal.
Some use cases can be solved by either by a CompositeKey or a Record and Tuple. Other cases like hiding the contents of the key and use in WeakMap are 'built-in' to CompositeKey but can also be implemented on top of R&T + Symbols as WeakMap keys.
I'm wondering if anything needs to be addressed for this proposal with regards to another Stage 1 proposal, RicherKeys' CompositeKey
The text was updated successfully, but these errors were encountered: