Do we need iterator/object property caching?

[littledan]

Is it necessary to cache object properties and iteration results? I believe this will be pretty difficult to optimize out in engines and transpilers without sacrificing correctness, so it may be a real performance cost at runtime. The "access multiple times" semantics seem pretty intuitive/direct to me.

I understand that there is some concern about exhausting iterators. However, array destructuring is for iterables--you always get a fresh call to [Symbol.iterator] before something else happens, and you could do your caching in there when it's important to you. I'm not sure if we should be defending against usage patterns where iteration is destructive.

(I thought I had an issue thread about this, where I was worrying about soundness/consistency, but the current Map approach is consistent; anyway, I can't find that old thread, so filing a new one.)

[ljharb]

It’s discussed a lot in #216.

tldr, yes - without the caching, you can’t match against the first N items and then the first N + 1. iterables aren’t reusable either - there’s no guarantee that iterating twice is possible.

[Jack-Works]

I agree cache is slow and hard to implement. I think it's possible to remove them to speedup common cases and break for special objects & iterators.

[littledan]

@ljharb I understand that argument and I think performance and simplicity of common cases is the concern of overriding importance.

[ljharb]

For the "iterators aren't reusable" piece, yes. Are you suggesting it's reasonable, in this example, to create three separate iterators from the iterable?

match (arr) {
  when [a]: …;
  when [a, b]: …;
  when [a, b, …]: …;
}

[littledan]

Yes.

[ljharb]

This would mean that pattern matching can't ever safely take an iterator - including something from iterator helpers, like match (arr.values().map(m).take(n)) {. That seems like it'd be a pretty common case.

[tabatkins]

Right, having to eagerly cast such things into an array seems... unfortunate.

[jaskp]

This would mean that pattern matching can't ever safely take an iterator - including something from iterator helpers, like match (arr.values().map(m).take(n)) {. That seems like it'd be a pretty common case.

@ljharb What makes such a case seem common when iterator helpers haven't landed yet and iterators are generally rarely used in JS? And basically all functions typed to accept sequences of values in TypeScript expect materialized arrays, not iterators, which I believe would slow down adoption even further. Rust and Python can't match on iterators either, can they?

Right, having to eagerly cast such things into an array seems... unfortunate.

@tabatkins Can you please elaborate on why you consider match ([...arr.values().map(m).take(n)]) {} unfortunate?

[ljharb]

@jaskp iterator helpers are polyfillable and are currently shipped in Chrome.

That's unfortunate because it's creating an array unnecessarily, and it's extra boilerplate that users will have to type.

[Jack-Works]

what if we eagerly consume the iterator at the first time when we need an array match?

[jaskp]

@jaskp iterator helpers are polyfillable and are currently shipped in Chrome.

That's unfortunate because it's creating an array unnecessarily, and it's extra boilerplate that users will have to type.

@ljharb is there some example of when you would want to match against an iterator? I can't really think of such a situation. I expect most matching to be done on POJO's and tuple-like arrays to discriminate between shapes. The only matching that currently makes sense to me in the context of an iterator is something like this

someIterable.values().map(elem => match (elem) { ... })

So it's a bit difficult for me to imagine a situation where it's wise to match against an iterator, I might have missed something in the discussion though. Perhaps the use-case is something JS specific and that's why Rust and Python don't need it?

And if some iterator really wanted to be matched against, couldn't that be implemented in the iterator itself and moved outside of this proposal? Iterators are stateful after all.

[ljharb]

@jaskp there are tons. arrays, maps, and sets all have .keys(), .values(), .entries(), specifically so you can choose which kind of iterator you want. The Iterator.range proposal will create an iterator as well, as will all of the iterator helpers.

"iterator" is a first-class thing - "iterable" is not.

[jaskp]

there are tons

@ljharb can I see one? (one situation where you should be matching on an iterator)

[ljharb]

I just named a few. When i want to check a map’s values, instead of the entries, for example.

[jaskp]

@ljharb Sorry for the misunderstanding, I meant an example of a specific situation, such as the "motivating examples" in the proposal.

Basically I would like to challange the notion that matching on iterators is useful, because I can't come up with a situation where it would be useful, so it seems like unnecessary complexity that is slowing this proposal down.

For a sanity check, I prompted ChatGPT and, although it completely hallucinated the syntax, it could only come up with a similar (counter)example as mine, i.e. matching on elements of the iterator, not the iterator itself:

function* mixedIterator() {
    yield 42;
    yield "hello";
    yield 3.14;
    yield "world";
    yield true;
}

for (const item of mixedIterator()) {
    match (item) {
        case let number:
            console.log("Found a number:", number);
            // Process the number
            break;
        case let string:
            console.log("Found a string:", string);
            // Process the string
            break;
        default:
            console.log("Found another type:", item);
            // Handle other types
    }
}

So is anyone aware of any motivation to support matching on iterators?