Stage 3 Checklist

[rricard]

• Spec text
• Reviewers
  • @ljharb
  • @rkirsling
  • @brad4d
  • You? Let @rricard:mozilla.org know on matrix if you want to be a reviewer.
• Editors
  • @bakkot
  • @syg
  • @michaelficarra

Action Items

• Move JSON.parseImmutable to a separate Stage 2 proposal: JSON.parseImmutable as a separate companion proposal #330
• Items being discussed:
  • Writeable wrapper objects for symbol keys? Should we allow the wrapper object to have additional symbol properties #137
  • Replacement for brand checking that is not Record.isRecord & Tuple.isTuple: part of Record.isRecord returning true for Record Exotic Objects #333
  • Usefulness of string conversion: part of Record toString: useful, useless, or thrown(in implicit conversions) ? #136
• Review items:
  • Various spec fixups: various: Spec fixups #325
  • Record.isRecord & Tuple.isTuple shouldn't work on R&T object wrappers: part of Record.isRecord returning true for Record Exotic Objects #333 & review: Record(Object(recordPrimitive)) should detect and return internal slot value #329
  • No implicit conversion to strings: part of Record toString: useful, useless, or thrown(in implicit conversions) ? #136
  • Make R&T usable in other existing places of the language: Make tuples usable as "entry" objects #107, Expand R&T support across methods that accept objects and arrays #264, Allow Records and Tuples where objects/arrays are currently allowed/supported #318, using Records where only Objects are currently permitted: [[Prototype]]? #326
  • Remove IsConcatSpreadable checks from Tuples, explicitely check for Arrays and Tuples: change Tuple#concat to spread on IsArrayOrTuple, not IsConcatSpreadable #328, Avoid looking up @@isConcatSpreadable for tuples. #334
  • Record.isRecord & Tuple.isTuple removal: Removal of Record.isRecord & Tuple.isTuple #335
• Planned Editorial Changes
  • ECMA262 name clash with "Record": "Record" name clashes with spec-internal "Record Specification Type" #96
  • WebIDL Record clash: Naming conflict with WebIDL's record<K, V> #116

---

Thank you all for the feedback in the previous plenary, I hope I listed all outstanding items so far. Special thanks to @ljharb & @rkirsling to have volunteered as reviewers.

[rkirsling]

Opened #345. 🙂

[ljharb]

Opened #349.

[lin72h]

Any update on this?

[acutmore]

Hi @lin72h here are the notes and slides for R&T from the last TC39 plenary (Nov 2022). One of the current concerns is from implementers on the technical challenges of implementing and supporting R&T, and a request to explore if there are ways to reduce the implementation cost while meeting the same core goals.

[lin72h]

Thanks for the links. Really looking forward for R&T coming in 2023

[bionicles]

May we have an update on this?

Anecdote: In Rust yesterday, I replaced a mutable vector type Vec<T> with an immutable slice Arc<[T]> and observed a 71% speedup to a hot path, got me thinking about this proposal again.

I believe this speedup may due to the ability to do reference counting rather than copy underlying data, better handle bounds checking if bounds are static, reduce memory allocation, and cache or otherwise accelerate things like equivalence checks and hashes.

Given Records and Tuples could yield big performance benefits for popular frameworks like React, Vue, Svelte, and Angular for similar reasons, do you think performance opportunities could warrant reconsideration of the cost:benefit analysis for this proposal? Seems promising and I hate to see it languish!

[acutmore]

Hi @bionicles. I've posted an update in #393.

I replaced a mutable vector type Vec with an immutable slice Arc<[T]> and observed a 71% speedup to a hot path, got me thinking about this proposal again.

I do not expect this performance gain to be applicable with JavaScript. Arrays are already pass by reference, so are not being implicitly copied and if code is currently spreading them like: ...arr then this work will almost certainly still happen if the code switched to using tuples. I do think there will be performance improvements opportunities for code that is currently creating defensive copies of values, they could check if the value is already a R/T and avoid creating a copy - but this wouldn't happen "out of the box" - could would need to be written in a way to gain this advantage.

[ljharb]

(Nothing in JS is passed by reference; everything including objects is passed by value https://web.archive.org/web/20161005155047/http://www.jon-carlos.com/2013/is-javascript-call-by-value-or-call-by-reference/ )

[acutmore]

Sure, though the value being copied is a reference.
I usually avoid saying "pass by ref/val" and should have continued to do so as I find the mental model doesn't communicate universally well.