I think this is too complicated for a proposal that doesn't have defined semantics yet.

This notation can be used for slice operations on primitives like String and any object that provides indexed access using [[Get]] like Array and TypedArray.

It is used to limit the slicee to string, array and typed array. Surely we can debate about whether we should loose the control here and allow any fancy objects as long as they implement indexed access.

That matches array-likes, too, eg { length: 1, 0: 'test' }. Let TypeScript handle type errors.

That matches array-likes, too, eg { length: 1, 0: 'test' }.

Yes, array-like objects is supported.

const obj = { 0: 'a', 1: 'b', 2: 'c', 3: 'd', length: 4 };
obj[1:3];
// → ['b', 'c']

But we should reject the following Proxy exotic object

new Proxy({} , { 
  get(target, prop) {
    if (prop === "length") { return 1 }
    if (prop == 0) { return prop }
    return undefined
  }
});

any object that provides indexed access using [[Get]]

I think that this means that proxies should be allowed. For example, when using a properly defined proxy, [].slice works:

var obj = new Proxy({} , { 
  get(target, prop) {
    if (prop === "length") { return 1 }
    if (prop == 0) { return 3 }
  },
  has(target, prop) {
    return prop == 0;
  }
});

[].slice.call(obj); // [3]

cc @gsathya What should it do here?

Nit: We can use the array path for this, and join at the end.

My major concern on implementation is memory footprint and performance. We could shorten the helper if we convert string to array, but that means given a string str with length N, str[::M] will require N byte memory while the optimal should be N/M.

It seems super weird that Identifier is allowed, but normal expressions are not. 😞

Actually I like this design choice. If nested general expression is supported, we can expect pretty nested code and one would easily get confused with ternary operator. Think of

a[
 foo : (
   get_bar_from_qux()
 ) : (
  get_qux_from_quux()
 )
]

Surely we can open an issue on the proposal to discuss this choice.

I like this way much better.

Can you add more tests?

a[b:c];
a[b:c:d]
a[b:];
a[b::];
a[:c];
a[::d];
a[b::d];
a[:];
a[::];

Thanks. Addressed in 452c6cd.

We also need to check that expr.extra && expr.extra.parenthesized is false.

Correct, dogfooding another stage 3 proposal. 😝

Shouldn't this be this.expect, or be inside an if (this.eat(tt.colon))?
Also please add a test where this expectation is not respected, e.g. foo[1:2;3]

Shouldn't this be this.expect

No. Because the colon step part is optional.

In the case of foo[1:2;3], parseExpression will throw unexpected token error since ; could not start an expression.

However, I think you idea of putting parseExpression inside tt.colon check is more reasonable. Once tt.colon is not matched, we should expect ] since it's the end of slice expression. I have added testcase for foo[1:2;3].

In the case of foo[1:2;3], parseExpression will throw unexpected token error since ; could not start an expression.

What about foo[1:2 3]?

It would throw "unexpected token, expected ]" now since parseExpression is not guarded by tt.colon check.