Record and Tuple ECMAScript Proposal

[rricard]

Hello TAG!

I'm requesting a TAG review of Record & Tuple.

This proposal introduces two new deeply immutable data structures to JavaScript:

• Record, a deeply immutable Object-like structure #{ x: 1, y: 2 }
• Tuple, a deeply immutable Array-like structure #[1, 2, 3, 4]

Records and Tuples can only contain primitives and other Records and Tuples. You could think of Records and Tuples as "compound primitives". By being thoroughly based on primitives, not objects, Records and Tuples are deeply immutable.

Records and Tuples support comfortable idioms for construction, manipulation and use, similar working with objects and Arrays. They are compared deeply by their contents, rather than by their shallow identity.

JavaScript engines may perform certain optimizations on construction, manipulation and comparison of Records and Tuples, analogous to the way Strings are often implemented in JS engines. (It should be understood, these optimizations are not guaranteed.)

Records and Tuples aim to be usable and understood with external typesystem supersets such as TypeScript or Flow.

• Explainer¹ (minimally containing user needs and example code): https://github.com/tc39/proposal-record-tuple/blob/master/README.md
• Security and Privacy self-review²: The answer to all questions is "does not apply" - there is no known security-related issues so far with this proposal as this proposal does not expose any observable lifetime of those structures
• GitHub repo (if you prefer feedback filed there): https://github.com/tc39/proposal-record-tuple
• Primary contacts (and their relationship to the specification):
  • Rick Button (@rickbutton), author & co-champion, @bloomberg
  • Robin Ricard (@rricard), author & co-champion, @bloomberg
  • Daniel Ehrenberg (@littledan), advisor, @Igalia
  • Robert Palmer (@robpalme), Bloomberg/TC39 standards coordinator @bloomberg
• Organization/project driving the design: @bloomberg
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): None

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): @tc39
• The group where standardization of this work is intended to be done ("unknown" if not known): @tc39
• Existing major pieces of multi-stakeholder review or discussion of this design: TC39 Stage 1 consensus in October 2019; planning to ask for Stage 2 in July
• Major unresolved issues with or opposition to this design:
  • JS developers seem excited about Records and Tuples; haven't heard widespread opposition overall
  • Should Record wrapper objects have a null prototype? #71. (Current proposal: yes)
  • How should === on Records and Tuples behave with floating point #65 (Current proposal: Records and Tuples are ==/=== if their contents are completely identical)
  • How can Records and Tuples point to objects? (Current proposal: to start, rely on solutions in JS; considering various approaches in a follow-on proposal )
  • How can entries in Records and Tuples be updated (Current proposal: See idioms in , potential follow-on proposal for deep updates https://github.com/rickbutton/proposal-record-deep-spread in development)
  • Minor: Name clashes with ECMA262 and WebIDL internal concepts of "record" (Current proposal: rename the ECMA262 and WebIDL concepts)
• This work is being funded by: @bloomberg

You should also know that...

We are interested where you would think that Record and Tuple would be a good fit for Web APIs and what work and/or precisions you'd need from us to use it. Please note that at the moment we do not have a way to create something analoguous to classes in that proposal. THis is being considered as a potential follow-on proposal.

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

[hober]

Hi,

We discussed this proposal in a TAG breakout today, and overall, we're really happy with this proposal. We're particularly impressed with the comprehensiveness of the explainer. We should consider adding a Glossary section to our explainer explainer based on your work here.

Prior to this TAG review, I noted the naming clash with WebIDL. We're confident that both you folks and WebIDL folks have that well in hand. We wonder if both WebIDL and TC39 could proactively look for such naming collisions when beginning new work.

Thanks so much for bringing this to us. If your design significantly changes due to other feedback, we'd love to take another look.