Proposal Records (a new one)

💡 Ideas
5

Hi @conartist6!

As per your note from the other thread

Naturally some overlap with GitHub - tc39/proposal-composites · GitHub, which I am currently championing.

Here are some of the presentations I've given to the committee around this topic in the last few years:

The core observation is that when you have an immutable and inert (no side effects when reading) data structure this is ideal for the equality needed for Map and Set keys - they can guarantee being consistent, reflexive, symmetric, transitive.

This leads to a design cycle, when trying to create a proposal for composite map keys you end up with something like an immutable and inert record. And when you design an immutable and inert record you get close to something that would be a great candidate for composite map keys.

The exact solution for how the equality should work is still unclear with some open questions that I am working to resolve. But these questions do impact the design of the records themselves so does not fit well as a follow-on proposal. This is why I'm approaching the proposal from the equality perspective as the primary goal, as immutably falls out from that anyway.

One note is that both the Composite and Records&Tuples proposals were adding something more like a constructor/factory rather than a "transform". An object can't become a composite after it is created. Doing Composite(obj) creates a new object based on the properties of the obj passed in. It is not like Object.freeze. This is primarily because of the equality aspect - for equality to be consistent the mode of equality has to be fixed from creation time.