# Proposal Records (a new one)

**URL:** <https://es.discourse.group/t/proposal-records-a-new-one/2546>\
**Category:** 💡 Ideas\
**Created:** [April 20, 2026, 3:50am UTC](https://es.discourse.group/t/proposal-records-a-new-one/2546 "2026-04-20T03:50:27Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![aclaymore](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/aclaymore/32/501_2.png) [@aclaymore](https://es.discourse.group/u/aclaymore)\
**Post date:** [April 20, 2026, 1:24pm UTC](https://es.discourse.group/t/proposal-records-a-new-one/2546/5 "2026-04-20T13:24:58Z")

</div>

Hi @conartist6!

As per your note from the other thread

> [@Object.freezeRecord](https://es.discourse.group/t/object-freezerecord/2543/2):
>
> @aclaymore Both the most closely related proposals, proposal-record-tuple and proposal-composites, are yours. I guess that means I'm especially interested in your feedback!

Naturally some overlap with [GitHub - tc39/proposal-composites · GitHub](https://github.com/tc39/proposal-composites), 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:

- [Records and Tuples - TC39 Nov 2022 - Google Slides](https://docs.google.com/presentation/d/1nJFe5aIT4RO9_MyVgc7zqyv4C12Pv6GPee77ATHzS_g/)
- [Records and Tuples - 2024 - Google Slides](https://docs.google.com/presentation/d/1JfChmW8tQ2_mrFDynosNqa1tjJ2j-qX6WoKm8vc_tkY/edit?usp=sharing)
- [Records and Tuples - 2025 - Google Slides](https://docs.google.com/presentation/d/1uONn7T91lfZDV4frCsxpwd1QB_pU3P7F6V2j9jEPnA8/edit?usp=sharing)
- [Composite April 2025 - Google Slides](https://docs.google.com/presentation/d/1n7lj_y02f4QjrTMvRGs3aZXt_zji5nSVYGhmVchMpvI/)
- [Composite November 2025 - Google Slides](https://docs.google.com/presentation/d/1ByfhAVVeEfeBj2g8TkP6f55hSmq8_8tevUxuRQLfISg/)

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.

---

_[View the full topic](https://es.discourse.group/t/proposal-records-a-new-one/2546)._