extension to slice-expression

[caub]

I propose to rename this proposal to "proposal-slice-expression", because I propose to have a syntactic representation for the SliceExpression, and 2 behaviors:

• if a sliceExpression is the property of a (dynamic) MemberExpression, it will evalutate to object[Symbol.slice](sliceExpression.startIndex, sliceExpression.endIndex, sliceExpression.step) (cf Consider basing the semantics on a method call #1)
• else, it will evaluate to an iterator:

(function* (si, ei, step) {
  if (step < 0) {
    for (let i = ei - step; i >= si; i += step) yield arr[i];
  } else {
    for (let i = si; i < ei; i += step) yield arr[i];
  }
})(sliceExpression.startIndex, sliceExpression.endIndex, sliceExpression.step)

@rbuckton proposed something similar in #19, I think we should not consider AssignmentExpression (arr[0:2] = [3,4]) because strings are immutable, the added complexity is probably not worth either

[gsathya]

if a sliceExpression is the property of a (dynamic) MemberExpression, it will evalutate to object[Symbol.slice](sliceExpression.startIndex, sliceExpression.endIndex, sliceExpression.step) (cf #1)

This seems like a fine idea.

else, it will evaluate to an iterator:

This is best left to the range proposal: https://github.com/tc39/proposal-Number.range
I want the slice notation to do just one thing, not several things depending on the context. Given that, I don't think it makes much difference whether it's called slice expression or slice notation (unless I'm missing something).