proposal-change-array-by-copy VS proposal-record-tuple

The new change array by copy methods (ES2023) will also work with tuples. So while you can't

Change Array by Copy

Stage 3 Change array by copy proposal offers methods like sortTo() that return a new array instead of mutating the original.

Note: there's a stage 3 proposal that introduces copy = arr.toSorted().

Change Array by Copy: Provides additional methods on Array.prototype and TypedArray.prototype to enable changes on the array by returning a new copy of it with the change.

The proposal is described here, with the other methods being:

Proposal, Polyfill

You're unlikely to see any new methods being added to JavaScript's Array that would modify an array in place like reverse() and sort() do. In fact some of the new methods that are being added are versions of reverse() and sort() (and splice()) that create copies rather than modifying the originals. Read more about them here: Proposal: Change Array by copy.

Since cloning is so common, a new specification has been written which has reached stage 3, which will give us a host of new ways to copy and then change an array. This proposal is called the "Change Array by Copy" proposal. Let's take a look at how it works.

relevant issue, which is at the crux of this problem: https://github.com/tc39/proposal-record-tuple/issues/387

There are still so many basic things that aren't in the JS stdlib, though. A good example is Map - if you need to use a tuple of two values as a key, you're SOL because there's no way to customize key comparisons. Hopefully we'll get https://tc39.es/proposal-record-tuple/ eventually, but meanwhile languages ranging from C++ to Java to Python have had some sensible way to do this for over 20 years now.

If you’re reaching for structuredClone, what you really want is native immutable Record and Tuple syntax, and the companion “deep path properties” syntax which allows for efficient and ergonomic immutable updates:

- https://github.com/tc39/proposal-record-tuple

It will be called "record" in JavaScript which will swing the popularity back the other way I guess (currently a language proposal)

I suspect considering the strong desire to maintain consistency with JavaScript, we will eventually see something that when the Record proposal passes through tc39

I hope the Record and Tuple proposal makes it through

I mean, I'd love some real immutable/persistent data structures in JS by default, or even some Immer-like syntax sugar. Something like the record/tuple proposal would be awesome.

This will become very useful once Records and Tuples are a thing, because it allows you to store object references in a record/tuple (which by definition can only contain primitives).

Record and tuple is at stage 2

Also, js has an ongoing immutable value data types proposal.