New iterator helper and binary iterators

[Kingwl]

I have draft a proposol to add two new method(findLast, findLastIndex) into array(typed array) object. And I think it's should be considered in this proposal.

And Iterator does not support some behavior like walk from end to start yet. And so It's might should consider https://github.com/tc39/proposal-deiter too.

Thanks.

[ljharb]

Given that this proposal is stage 2, and your new proposal has no stage, it seems like it would make more sense for your proposal to also include your new Array methods as iterator helper methods, rather than adding them here.

[Kingwl]

IMO, It's dependence on https://github.com/tc39/proposal-deiter or https://github.com/tc39/proposal-reverseIterator, doesn't it?
If so, seems they are not stage too...

BTW: It's just a note

[ljharb]

This proposal isn’t dependent on anything else, afaik.

[hax]

I think if findLast/findLastIndex could achieve stage 2 before this proposal goto stage 3, maybe we can just add corresponding new iterator helpers in this proposal. Anyway we can always add new iterator helpers in follow-on proposals.

[ljharb]

It seems far more likely that iterator helpers will hit stage 3 first, which means findLast would need to add the helpers it wants.

[Jack-Works]

how can we iterator from the end (to use findLast) without https://github.com/tc39/proposal-deiter?

[ljharb]

ah, very good point.

[Jamesernator]

Even without double-ended iterators .findLast can still be useful if you simply want the last value matching some condition. This is particularly useful in async iterators for retreiving the "most recent" value matching a condition.

[Jack-Works]

Even without double-ended iterators .findLast can still be useful if you simply want the last value matching some condition. This is particularly useful in async iterators for retreiving the "most recent" value matching a condition.

I'm doubting if it is a good idea to implicitly consume the whole iterator to the end and drop the middle result. It may be better to use .toArray().findLast() to explicitly mark it as "consuming everything" (I don't know if there is already this kind of iterator helpers).

[callionica]

Traversing an entire sequence and creating an array from the entire sequence have pretty different memory requirements for large sequences, so it.toArray().findLast() and it.findLast() would be different in that regard.

[michaelficarra]

For behaviour that matches Array.prototype.findLast, the whole iterator would have to be consumed and stored before invoking the callback on each element starting at the last one. I could imagine wanting a "find last element which passes some predicate" method that operates on every element from the front, avoiding the need to store the iterated elements, but we couldn't possibly call that findLast since that has different behaviour (due to possible side effects in the passed callback).

[hax]

Yes, findLast will only have "correct" semantic if it is an double-ended iterator (havingnextLast() which consume the "last" item in the seq). So I hope to add them to deiter proposal.