Potential for reified Index type

[rbuckton]

I mentioned this in tc39/proposal-slice-notation#19 as well, but there is potential to augment this in the future with an actual reified Index type, similar to C#, in a follow-on proposal to both this and slice notation, such that you could have a literal syntax for slices and index-from-end, i.e.:

const s = (1:3); // new Slice(1, 3, 1)
const i = ^1;    // new Index(1, /*fromEnd*/ true)

const ar = ["a", "b", "c"];

ar[s]; // ["b", "c"]
// desugars to:
// s[Symbol.geti](ar) -> ar[Symbol.slice](s)

ar[i]; // "c"
// desugars to
// i[Symbol.geti](ar) -> ar[i.getIndex(ar)]

Please note this is intended as a discussion topic for a follow-on to this proposal. I primarily want to make sure we're thinking about this possibility as this proposal evolves.

[ljharb]

Why would we need or want some kind of Noun?

[rbuckton]

It's extremely convenient to be able to hold on to slices and relative indexes in variables and reuse them, which is why both C# (Range and Index) and Python (slice) have them as well. Plus, the plumbing necessary to make these objects work would be very useful for things like WeakMap.

[hax]

@rbuckton Yes, I believe I've already expressed my support for your entire concept in that issue. This proposal merely aims to isolate and clarify the need for index-from-end, the capabilities required, and the design constraints, which can then be explained and encompassed by the more general mechanism you propose in your future proposals.

I had thought that this would better demarcate the problem and facilitate progress. I thought it was in line with TC39's past practices, but unfortunately, I have failed. I'm not sure where the problem lies—perhaps it's a lack of ability on my part. I'm uncertain about what more I can do. Maybe your Symbol.geti/seti proposal is the only hope. Overall, I have always been very supportive of your various JS proposals, and if there's anything I can do to help, please let me know.