Stronger Motivation

[gsathya]

At the last TC39 meeting, there was strong pushback that this feature didn't really solve any problem.

The main motivation for me was developer ergonomics: shorter to type than slice(). And having a ton of other mainstream languages provide similar slicing capability showed the demand and value for this feature.

Both of these didn't seem to be convincing enough, are there other reasons to have this feature?

[hax]

The original proposal includes step, but it could be solved by add third param on slice method, so I am not sure whether it could make any difference.

Personally I think a[^1] (index from end syntax) is attractive, which solve the argument of a[0:-1] work but a[-1] not. If we could have a[^1] it may be have stronger motivation to have a[0:^1], and in a[0:^end] end could be 0, which same as a[0:(a.length)], this solve the slice issue: a.slice(0, -end) returns empty instead of whole array if end is computed to 0.

[hax]

I think we could extend the motivations to:

• developer ergonomics
• easy to understand and use
• avoid the gotchas of current slice() (and splice(), at()) methods

The gotchas:

• -0 case
• unexpected -1 case (result of indexOf/lastIndexOf)
• a[idx] and a.method(idx) have different coercion rules
• NaN is coerce to 0, so [1,2].at("last") give u 1 😂
• float case, [1,2].slice(0.9999999999999999) give [1,2], [1,2].slice(0.99999999999999999) give [2],
• negative float case, [1,2].slice(-1.5) give u [2], but [1,2].slice(len-1.5) give u [1,2]
• string.slice() is not code-point safe, can cause bugs which mainly only affect international users, mark such issues "edge case" is really “racist” (and in some cases like emoji, everyone could be hit).
• splice() is a bad api, a[start:end] = iterable would be a much better way.

Maybe we can not solve all gotchas , but we should at least have a try.

[hax]

As previous meeting, I don't think "stronger motivation" is the problem now. So I close this. See also https://github.com/tc39/proposal-slice-notation/issues/45#issuecomment-1835388392 .