| 18:57 | <jschoi> | I’m working on #3581 (Array.fromAsync). It looks like Array.from’s iteration machinery has changed a lot since I last checked. Now Array.from uses a new IteratorStepValue operation. There’s no analogous AsyncIteratorStepValue operation yet, is there? |
| 19:03 | <bakkot> | Correct |
| 19:03 | <jschoi> | Would it be worth for the Array.fromAsync pull request to define new AsyncIteratorStepValue, AsyncIteratorStep, and AsyncIteratorNext operations, to match Array.from’s algorithm? |
| 19:04 | <bakkot> | No, probably not until there's more stuff which uses it |
| 19:05 | <bakkot> | You can use the underlying operations, though |
| 19:06 | <bakkot> | IteratorNext works fine on async iterators I think |
| 19:06 | <bakkot> | and then after awaiting the result you can use IteratorComplete and IteratorValue |
| 19:08 | <bakkot> | which I guess is pretty much what you're doing already, except manually calling .next instead of using IteratorNext, which is fine |
| 19:08 | <bakkot> | don't worry too much about esmeta errors; if they don't look like actual errors you can ignore them |
| 19:09 | <bakkot> | it isn't capable of handling everything in the spec and there's a file we can use to mark things as expected errors if we decide it's an esmeta bug |
| 19:10 | <bakkot> | in this specific case, yes, it looks like it's because of not recognizing the new IfAbruptCloseAsyncIterator macro, which makes sense; macros are hard to typecheck and we don't have any explicit marking for them |
| 19:29 | <jschoi> | Thank you very much for your great help. |