should AsyncIterator.protoype.filter have a fast path for sync predicates?

[michaelficarra]

As mentioned by @rbuckton in #117 (comment).

Also it was questioned whether true/false should be the fast path or truthy/falsey non-thenables. I would only support true/false.

[zloirock]

Why only true / false? It can be at least all primitives - someone returns 0 or undefined as something falsy.

[devsnek]

Given the choices:

• always await
• await if not true or false
• await if IsPromise

I would choose always await, it seems to be the least chaotic.

[zloirock]

@devsnek IsPromise works only with native promises - but it can be a userland implementation, so it's not an option.

[devsnek]

@zloirock yes i agree.

[michaelficarra]

@zloirock Yes we could support other primitives, but it gets more murky. What would the algorithm be? If it's an object, assume it's thenable, otherwise ToBoolean it? It would prevent weird things like putting a then method on String.prototype, but that's probably okay.

[ljharb]

The algorithm would be if Type is Object, go the slow path. Seems reasonable to me.

[bakkot]

If we allow other primitives it's likely to run into weird timing issues. It's easy to image a predicate function which returns either an object or null, whcih would have an extra tick only in the null case. By contrast a predicate function which returns only true or false would have a consistent number of ticks in both cases.

On the other hand, maybe "number of ticks" is a thing not really worth caring about?

[ljharb]

Only in that the desire is to minimize them in a predictable way, which i think “returns an object or null” achieves.

[devsnek]

I think in these cases the more important thing is consistent behavior. this await will not be the "slow" part of real world code, the I/O from whatever async api is driving it will be.

[zloirock]

.filter optimization is not the most interesting similar case. For example, why we should await the result of AsyncIterator.protoype.forEach sync callback that in many cases will return just undefined?

[ljharb]

Because those need to be run in serial; filter operations do not.

[zloirock]

Nope. All methods from this proposal should be run in serial, .filter too. I mean sync .forEach callback. If the result of the callback is undefined or another primitive, not promise. Similar to true of false for .filter from this issue.

[ljharb]

What i mean is, conceptually, forEach is for side effects - filter is supposed to be pure.

Obviously they all need to run in order, but failing to await forEach would cause bugs in otherwise reasonable code - filter would not.

[bakkot]

It's not obvious to me how failing to await forEach would cause bugs in the specific case that the function passed to forEach returned undefined. We'd have to wait when it it returned a Promise, of course, but I don't see a problem (except for consistency) with avoiding the await undefined in the case that the function passed to forEach synchronously returns undefined.

[zloirock]

...and the same situation with callbacks of almost all methods from this proposal - .map, .every, etc. - they are similar here and the resolution of this issue should be similar for all of them.