Cryptic syntax

[stevenvachon]

I think that our codebases would better off without this. With that, I think this proposal should be dropped. That's my opinion.

[ljharb]

You’d have to elaborate.

[stevenvachon]

arr[1:3]; // what is this?
arr.slice(1, 3); // can research Array::slice

str[6:]; // what is this?
str.slice(6); // can research Array::slice

arr[::-1]; // what is this?
arr.slice().reverse(); // can research each of these

[ljharb]

You can research any syntax; that’s not evidence of anything really.

[stevenvachon]

It's more difficult to research a nameless, unknown syntax than it is to research a method/function name. Such syntax increases the complexity of the language, which is fine when there is a major benefit; but this proposal offers little of that. Comparatively, arrow functions increased complexity, but are a success because they reduce a very common mention of function; while array slicing is not as common.

[ljharb]

Do you have evidence that it’s not that common? I suspect doing a GitHub code search for “.slice” will yield a great many results.

[stevenvachon]

Sure, slice is used a lot, but in a codebase, you will have far more functions than slices.

[ljharb]

ok, but if slice is used a lot, how is it not common? That other things exist that the language may need doesn’t negate the usefulness of this proposal.

[stevenvachon]

It's used a lot in general along with much of the language, but not so much within an application that we should avoid using Array::slice. We can already accomplish the same goals of this proposal with already minimal code.

[j-f1]

I think this is a good motivation?

const arr = ['a', 'b', 'c', 'd'];
arr.slice(3);
// → ['a', 'b', 'c'] or ['d'] ?

[ljharb]

@j-f1 i'm not sure how that changes the argument; if you don't know how slice works you won't know how slice notation works either.

[stevenvachon]

@ljharb his example is taken from this proposal's readme. I agree that it isn't valid in describing the new syntax as an improvement.

[topaxi]

Methods are nice and all until you see a code base with ''.slice(), ''.substr(), ''.substring(), [].slice() each with different arguments... of course, adding a syntax feature adds another way to do slices, but having a encouraged way by the language could help.

[ljharb]

@j-f1 @stevenvachon ah, gotcha. the ensuing prose in the readme explains why that's part of the motivation in a way that makes sense.

[stevenvachon]

@topaxi I'm assuming those examples are simplified, because a realistic [].slice() wouldn't be much different from this proposed syntax.

[topaxi]

@stevenvachon my point was that a standardized way across any datastructure would keep the argument order and meaning consistent.