Alternative approaches

[FrameMuse]

Description

I'm sorry if understood the proposal wrong or didn't research it well enough but why it's better to have toReversed(), toSorted() along with reverse(), sort()? (I can agree with toSpliced() and with(...))

I can't really see the problem to just use spread syntax or "standard" method, I'll demonstrate it on your examples.

reverse()

Proposal approach

const sequence = [1, 2, 3];
sequence.toReversed(); // => [3, 2, 1]
sequence; // => [1, 2, 3]

Spread syntax approach

const sequence = [1, 2, 3];
[...sequence].reverse(); // => [3, 2, 1]
sequence; // => [1, 2, 3]

sort()

Proposal approach

const outOfOrder = new Uint8Array([3, 1, 2]);
outOfOrder.toSorted(); // => Uint8Array [1, 2, 3]
outOfOrder; // => Uint8Array [3, 1, 2]

"Standard" approach

const outOfOrder = new Uint8Array([3, 1, 2]);
new Uint8Array(outOfOrder).sort(); // => Uint8Array [1, 2, 3]
outOfOrder; // => Uint8Array [3, 1, 2]

Conclusion

As you can see it's not a big problem to solve this with already existed methods it's niether making code a lot longer nor more complicated.
If you can give more examples on what your proposal solves with real-world examples, otherwise it's just polution of the Array and TypeArray, a newbie would barely see the diffrence and why there splice() and toSpliced() at the same time.

Again, maybe I don't get it and not taking something to an account. However your examples showing only with(...) usage as "reasonable" (as for me).

[ljharb]

Both of your alternative approaches make a new array, and then mutate it. The goal is to avoid the mutation entirely.

[syg]

Both of your alternative approaches make a new array, and then mutate it. The goal is to avoid the mutation entirely.

The current proposal certainly still has mutation in it, so not sure what you mean.

[acutmore]

hi @FrameMuse

A core motivation for this proposal is to keep the Tuple interface as a subset of the Array interface.
https://github.com/tc39/proposal-change-array-by-copy#relationship-with-record--tuple

Because Tuples are immutable they won't have a sort method on them, they will have a different method which does a non-mutating sort. Because Arrays already exist adding methods to them has a web compatibility risk, so it makes some sense to update the Array interface first - ensure it is web safe. And then the Record/Tuple proposal can follow.

[FrameMuse]

Because Tuples are immutable they won't have a sort method on them, they will have a different method which does a non-mutating sort. Because Arrays already exist adding methods to them has a web compatibility risk, so it makes some sense to update the Array interface first - ensure it is web safe. And then the Record/Tuple proposal can follow.

I guess it would be nice if you mentioned it in README.md, because I read it and it was not clear enough for me.

[FrameMuse]

Because Arrays already exist adding methods to them has a web compatibility risk, so it makes some sense to update the Array interface first - ensure it is web safe. And then the Record/Tuple proposal can follow.

I'm not really into Tuple & Record but why not having these methods directly on Tuples?
And you said that

...Tuples are immutable they won't have a sort method on them, ...

and then

... they will have a different method which does a non-mutating sort.

Isn't it controversial? Or you meant that they won't have a sort method as in Array but their own. If so, I'm sorry but I still can't see the reason why Array should have these methods as well.

[ljharb]

@syg in what way? each of the methods in this proposal returns a new array and does not mutate the original one.

[FrameMuse]

Both of your alternative approaches make a new array, and then mutate it. The goal is to avoid the mutation entirely.

Soo, why do you need this then? Is it much more efficient than mutating a new array? Does it solve a bigger problem? - I didn't see any problems of that king stated in the description.

[FrameMuse]

@syg in what way? each of the methods in this proposal returns a new array and does not mutate the original one.

Yes, you're right, they don't mutate it just the same as in my examples - the original arrays are not mutated.

[syg]

@syg in what way? each of the methods in this proposal returns a new array and does not mutate the original one.

Well you didn't say "mutation of the original", the original comment was "avoid mutation entirely", which... isn't true? That said I agree with the symmetry argument with R&T.

[ljharb]

@syg fair, i meant, avoid user-observable mutation, which applies to these methods.

[acutmore]

Because Tuples are immutable they won't have a sort method on them, they will have a different method which does a non-mutating sort. Because Arrays already exist adding methods to them has a web compatibility risk, so it makes some sense to update the Array interface first - ensure it is web safe. And then the Record/Tuple proposal can follow.

I guess it would be nice if you mentioned it in README.md, because I read it and it was not clear enough for me.

Yes, the README could make this clearer. Counter-intuitively it can be difficult to remember to keep a proposal's README up to date because it is not one of the formal documents. When a proposal is being discussed at the TC39 meetings we talk about the formal specification and present slides - and do not tend to look at the READMEs.

If you look through the TC39 agenda repository you'll be able to find links to when the proposal was presented and links to the slides shown, which go into the motivation of the proposal more.

https://github.com/tc39/agendas/blob/main/2022/03.md

---

Because Arrays already exist adding methods to them has a web compatibility risk, so it makes some sense to update the Array interface first - ensure it is web safe. And then the Record/Tuple proposal can follow.

I'm not really into Tuple & Record but why not having these methods directly on Tuples? And you said that

...Tuples are immutable they won't have a sort method on them, ...

and then

... they will have a different method which does a non-mutating sort.

Isn't it controversial? Or you meant that they won't have a sort method as in Array but their own. If so, I'm sorry but I still can't see the reason why Array should have these methods as well.

Maybe a code example would be a better way for me to explain:

function processList(list) {
  return list.map(v => someFunction(v)).sort(); // only works on arrays, because there is no Tuple.prototype.sort
}

compared to:

function processList(list) {
  return list.map(v => someFunction(v)).toSorted(); // now works with both arrays and tuples
}

If Tuple.prototype wasn't a supertype of Array.prototype. The function couldn't rely on duck-typing, it would need to make things more explict:

function processList(list) {
   const inputWasTuple = Tuple.isTuple(list);
   const arrayInput = Array.isArray(list) ? list : Array.from(list);
   const result = arrayInput.map(v => someFunction(v)).sort();
   return inputWasTuple ? Tuple.from(result) : result;
}