Is this proposal stalled/blocked?

[josephrocca]

I've recently been thinking about how an ergonomic matrix-crunching library (like Python's numpy) would look in JS, and remembered this proposal, but it looks like there hasn't been much movement in quite a while.

I'm wondering if someone who has been close to this proposal could provide some high-level context on whether it's stalled/blocked/etc, and the reasoning behind it?

Thanks!

[hax]

As I understand this proposal is blocked mainly because of a[1:-1] works but a[-1] never can work. There may be other concerns but I am not sure.

I have suggested to move to C# style reverse index (a[1:^1]) instead of negative index, and also add a[^1] syntax (see https://github.com/hax/proposal-index-from-end ). a[^1] proposal actually have been presented in TC39 meeting, but asked only can advance with the coordination with this proposal.

I am planning revisit these proposals and also champion this proposal with that direction, if current champion @gsathya agree.

[gsathya]

This biggest blocker is https://github.com/tc39/proposal-slice-notation/issues/40 -- which I think is solvable but I don't have bandwidth to take on. @hax, happy to add you as a champion if you'd like to push this forward.

[hax]

@gsathya I created a PR https://github.com/tc39/proposal-slice-notation/pull/46/files , and add me as champion. :-)

[hax]

Update: I plan to update the proposal (main points: https://github.com/tc39/proposal-slice-notation/issues/40#issuecomment-1176916994) and present it to the committee in the next meeting (hopefully Nov 29th or Nov 30th).

[josephrocca]

Exciting! Thank you for your work on this :pray:

[hax]

Update:

My index-from-end proposal is blocked by WH because he requires ^i syntax must have reification (which I don't agree and don't want to include it in the proposal), so we still not have index-from-end syntax for slice notation.

As my understanding, such result means it's very hard to get slice notation in next stage, because:

1. we want good syntax, in my opinion a[start:end] is the best
2. we want a[start:end] could cover all use cases of old a.slice(start, end)
3. a.slice support negative index
4. a[start:end] can't support negative index because a[i] don't support and never can support due to web compat requirments
5. a[^i] is blocked, even it's the best option I can find to replace negative index

I don't think I can do anything in current status.

Sorry guys, I already try my best.

Note: @bakkot , @rbuckton and @michaelficarra may have other thought, for example a[@value] which delegate to a[Symbol.get](value), and value could be the reififcation form for (^i) and (start:end). I don't object that but I feel a[@(start:end)] and a[@(^i)] has very bad ergonomics, even without parens, it's still bad. So the only possible option is still make a[start:end], a[^i] as the sugar of a[@(start:end)] and a[@(^i)]. And it's just the current design. So I don't understand why we can't make it and let follow-on proposal (eg. https://github.com/tc39/proposal-slice-notation/issues/19#issuecomment-523343697 ) to deal with the more general areas. I'm tired and very disappointed. That's all.

[S-Asakoto]

I wonder if removing the square brackets from the "bad ergonomics" a[@value] is probable. Like, if the problem is that a[-1] is incompatible with slice notation, and a[@(^1)] is too clumsy, what about using a@-1 to denote the element "at" position -1?

The problem is that we need to define a new @ operator and give it the highest precedence. This won't conflict with the decorator proposal I think (because you can only have an @ at the beginning of a line, declaration, etc., or after another decorator), but if somehow JS is to introduce matrix multiplication like Python this would be a problem.

Anyway in my mind, if removing the square brackets, then some possible syntax would be like:

• a@value
  • Same as a.at(value)
  • value can be a variable or a number literal (syntax error if not integer)
• a@(expression)
  • Generalization of the above, use parentheses to override precedence of @
• a@[start, end, step]
  • If the right operand is an array then it will be the same as a[start:end:step] in the original proposal
  • Can have empty values as in the original proposal. If the right operand has more than 3 items, only the first three are used
  • a@[] does the same as a.slice() or [...a], and a@[,,-1] does the same as a.toReversed()

So for implementation, a@value can be delegated to a[Symbol.get](value), where:

Object.defineProperty(Array.prototype, Symbol.get, {
    value: function(value) {
        if (typeof value === "number" && Number.isInteger(value)) return this.at(value);
        if (typeof value === "object" && value.every?.(Number.isInteger)) {
            let [start, end, step] = value;
            while (start != undefined && start < 0) start += this.length;
            while (end != undefined && end < 0) end += this.length;
            if (step != undefined) {
                if (step == 0) throw new RangeError("step cannot be 0");
                const temp = [];
                if (step < 0) for (let i = start ?? (this.length - 1); i > (end ?? -1); i += step) temp.push(this.at(i));
                if (step > 0) for (let i = start ?? 0; i < (end ?? this.length); i += step) temp.push(this.at(i));
                return temp;
            } else return this.slice(start, end);
        }
        throw new TypeError("value can only be an integer or an array of integers");
    },
    // other settings omitted
});