Why the naming

[regularlabs]

What is the reason by the name toSpliced() and not something like removeValues() or replaceValues()?
And why with() and not something like replaceValue()?

[ljharb]

toSpliced is because it's a non-mutating analogue to splice. Additionally, splice can both remove, add, and thus replace values.

[acutmore]

Some of the reasons for choosing with were brevity and also because of the similarities to its use in the Temporal proposal.

[acutmore]

One other reason for retaining the splice part of the name is so they both appear in auto complete.

If someone types arr.splice they are likely to see both splice and toSpliced in the autocomplete, which will perhaps be a subtle reminder that splice mutates and toSpliced is the non-mutating variant.

#10 (comment)

[david0178418]

Some of the reasons for choosing with were brevity and also because of the similarities to its use in the Temporal proposal.

Even with this, the choice of with still seems a bit cryptic.

Consider:

myArray.with(1, 2);

as opposed to

myDateTime.with({
    minute: 1,
    second: 20
});

The latter is more or less self documenting. The former, however, requires somewhat arcane knowledge since with doesn't sufficiently communicate what it does.

This could be fixed with a more expressive method name. Alternatively, more expressive parameters could be used:

myArray.with({
    index: 1,
    value: 2,
 });

[ljharb]

The proposal is shipped in browsers and just achieved stage 4 today; I'm reasonably confident there won't be any changes here.

[david0178418]

I'm torn between"D'oh" and "woohoo"😅

[mayfield]

This should have had more discussion IMO, so it's a bit disheartening to see that it's already shipping in browsers.

with is a dirty word in JavaScript so there will be some Pavlovian resistance to using this method on its name alone. My first thought when seeing it on MDN was that it was a legacy method I'd not heard of before and it should be avoided. In addition I agree with some of the comments above about the ambiguity of the calling signature. The name of the method alone does not convey how a tuple of arguments is acting on the array, let alone on a copy of the array. And finally, the word with conveys that the action is happening to/on the thing and not producing a thing.

No arguments against toReversed and toSorted, those will prove useful and highly legible. However splice has always felt like one of the ugly parts of JS to me and adding toSpliced does feel like throwing good money after bad. Generally when I use or see splice used, it's really just a hard to read version of python's list.pop(index).

TL;DR; I wish this proposal had been more conservative.

[ljharb]

To me, “with” absolutely and only connotes producing a thing that’s a combination of the inputs. A pizza is one thing, a pizza with pepperoni is a new thing produced by combining pizza and pepperoni.

i totally agree splice sucks, but toSpliced is objectively less bad because it doesn’t mutate.

[acutmore]

with is a dirty word in JavaScript so there will be some Pavlovian resistance to using this method on its name alone

Yep, this was considered a downside to this name. However the "dirty" with is a syntactic keyword, not a method. Also it is increasingly rare to stumble on usages of it due to only being supported in sloppy mode and strongly discouraged in all documentation. So I think that the majority of future JS developers will be unaware of the existence of it, and only familiar with the new methods on Array and Temporal.

FWIW, while this particular thread is short. We did spend over a year discussing the names of these methods and with all things considered I think we have ended up with good names. All names that were considered had at least one downside, there are no perfect names unfortunately.

[Sembiance]

with is a dirty word in JavaScript so there will be some Pavlovian resistance to using this method on its name alone

FWIW, while this particular thread is short. We did spend over a year discussing the names of these methods and with all things considered I think we have ended up with good names. All names that were considered had at least one downside, there are no perfect names unfortunately.

Could you provide a link to the the year of discussion you mentioned regarding the naming of this method?
I'd like to learn of the alternatives to "with" and learn where these dicussions take place to potentially take part in future discussions.

[acutmore]

Hi @Sembiance, if you haven't already I would recommend 'watching' the TC39 agenda repository: https://github.com/tc39/agendas/tree/main and/or the notes repository: https://github.com/tc39/notes

This proposal was presented:

• 2021/04 https://github.com/tc39/agendas/blob/258cdd128b018761f31e25ed9fe02842eabf1079/2021/04.md?plain=1#L93
• 2021/08 https://github.com/tc39/agendas/blob/258cdd128b018761f31e25ed9fe02842eabf1079/2021/08.md?plain=1#L89
• 2021/10 https://github.com/tc39/agendas/blob/258cdd128b018761f31e25ed9fe02842eabf1079/2021/10.md?plain=1#L99
• 2022/03 https://github.com/tc39/agendas/blob/258cdd128b018761f31e25ed9fe02842eabf1079/2022/03.md?plain=1#L97
• 2022/07 https://github.com/tc39/agendas/blob/258cdd128b018761f31e25ed9fe02842eabf1079/2022/07.md?plain=1#L97
• 2023/01 https://github.com/tc39/agendas/blob/258cdd128b018761f31e25ed9fe02842eabf1079/2023/01.md?plain=1#L95

This can be a good way to see what's happening and open Github issues to discuss parts of the design before it reaches Stage 4.

This particular proposal was split off from https://tc39.es/proposal-record-tuple/ so the discussions on methods names actually predate this proposal. The .with methods can be traced back to at least tc39/proposal-record-tuple#49 (sep 2019) where the R&T proposal switched from having a tuple with [i] = 2 operator and switched it to be a method tuple.with(i, 2).