Kevin Gibbons

@annevk A Proxy for a Set already does not behave like a Set: `Set.prototype.has.call(new Proxy(new Set, {}))` throws. (Similarly for platform objects like Image or whatever.) That's not really a...

I feel like it's not totally unreasonable to call `AsyncIterator.from` because you had a sync iterator and you wanted an async iterator.

That does happen to work, but only because `Iterator.from(x)` returns an iterable. But it's not something people are going to try without being told to try it, I would think.

The primary purpose of `AsyncIterator.from` is to ensure that the result inherits from `AsyncIterator.prototype`, in the same way that `Iterator.from` ensures the result inherits from `Iterator.prototype`.

I am tempted to resolve this by saying the `from` methods only take _iterables_, not iterators. That makes them marginally less useful for wrapping manually produced iterators; on the other...

It would be weird if a syntactic `await` did not in fact wait. But there's no syntactic `await` here.

It's true we could reasonably have had this fast-path there as well. Probably still could, for that matter.

This logic could probably be shared with `Iterator.from` and `AsyncIterator.from`, no? It's not exactly the same as written, but I think it probably should be the same. (Other than the...

It feels very strange for me to have `Iterator.from(string)` throw, given that `for (let c of string)` works. I am (very reluctantly) OK with `.flatMap` in particular guarding against strings,...

flatMap step 3.a.vi is > vi. Let innerIterator be Completion(GetIterator(mapped, sync)). and `GetIterator` consumes iterables.