I wonder if a generalized canParse solution for JS would be viable as an alternative to using eval or Function for syntactic feature testing

i'd swap those two but sure (thisArg goes last, just like all the array methods, since it's more optional than args)

... treeshaking seems like a pretty reliable mechanism in the current world in fact?

and which isn't granular enough to support packages with one side-effecting code path and many non-side-effecting code paths, eg

coinbase's react native app size dropped by 71% (seventy-one, not a typo) with that change

the lesson most of us have taken is, don't use barrel files :-)

Statically judging whether JS code has side-effects is hard - probably impossible - so compilers take a safety-first approach and bail out unless they are really sure dead code is safe to remove. This is why treeshaking is not always effective.

right, which is why i want to hear v8's position first

V8 is supporting the PR (https://github.com/tc39/proposal-iterator-helpers/pull/287) Michael talked about yesterday. This incompatibility blocked us for shipping iterator helpers. The solution provided in the PR seems to be the best way to resolve the issue.

thanks; and does v8 have an opinion about, instead of the PR, just not implementing the constructor and Symbol.toStringTag properties for the time being?

and additionally, with either approach, is Chrome willing to try to ship them as normal data properties in the future once the incompatible websites have finished upgrading?

mdn. every time

my vscode-fu need polishing for sure

Usually just array.slice( is enough assuming the language service knows array is an array type

though I don't see why you want to do it in this inverted way - it seems like usually containers know how to use an index, rather than an index knowing how to use a container?

the WeakMap example seems actively bad to me? if I see obj[key] = 1 I am really expecting to set a property on obj. if it does something other than that this is bad.

Could someone clarify if we're talking about just the slice 1:2 proposal now, or also the ^ one?

ljharb: I am imagining that map[^key] = value is sugar for map[Symbol.set](key, value)

the WeakMap example seems actively bad to me? if I see obj[key] = 1 I am really expecting to set a property on obj. if it does something other than that this is bad.

rbuckton: a[b] needs to have simple semantics

My suggestion is to add a new syntax for such cases.

I don't think we should change a[x], but I think we could reasonably introduce a[^x], which would allow a to define how it should be indexed by arbitrary x

If we introduced a new syntax for indexing, I'd be opposed to a[^x] specifically as I'd really like it to not mean different things in different places (negative index on Arrays, something else somewhere else, etc)

If we introduced a new syntax for indexing, I'd be opposed to a[^x] specifically as I'd really like it to not mean different things in different places (negative index on Arrays, something else somewhere else, etc)

there's only so much time I have to dedicate to TC39 stuff and I need to prioritise things

Thank you ! I just try to advance it it the simple form which I believe is the best solution on these problems.

engines will not let that highly-optimised, extremely common operation become slow

only if anyone anywhere has ever touched Symbol.toPrimitive, which they usually haven't

rbuckton: I encourage you to participate in the Iterator.range issue tracker

rbuckton: I don't see how they are different

Refication of index/range are good I believe, the problem is we never have such things in js, all js current methods are just calculate eaglely, for example, this is how resizeable typedarray deal with negative index.

Another problem, if there will be index/range I will really hope they are new primitive types. But it seems very impossible as current status.

Primitives aren't really necessary for this. Regular expression literals produce Objects

does this not fall under the "don't coerce objects to primitives"?

"you haveundefined notifications to review"

Hopefully in an Intl.MessageFormat world, that message would read:

you have {$count} notifications to review

As a counterpoint to a[@x] or whatever. if x is a reified slice, I would want a way to explicitly throw when it is used via a[x], since that would be a mistake.

but, I also don't see why it would be a mistake?

just make the Symbol.toPrimitive method on the Slice class throw?

ah, well, they would not be totally mutually exclusive

because Array could have a[@-1] do negative indexing

why? if I do map[@"string"], that can do a map lookup

Yes, if you use a key with a type of collection which does not know how to interpret that key, you're going to have a bad time. But this is also true in your inverted world if you use a key with a type of collection where the key does not know how to interpret that type of collection.

Ignoring the @ for a second, a[x:y] and a[^x] should always be interpreted as "take a slice from a" and "get the element from a relative from its end".

With my proposal also: Array.prototype[Symbol.get] = function(v) { if (Slice.isSlice(v)) return this.slice(v.start, v.end); /*...*/ }

(I really do not think it makes sense for keys to define how they interact with collections, rather than collections defining how they interact with keys.)

But yes, if you have a reified slice type, and you try to index a map by that, the appropriate behavior is to look up the slice instance in the map. That's how maps work.