The only place it seems to be documented is this issue thread and the actual specification. However, the reasoning for the removal isn't posted anywhere I could find.
The new recommended way seems to be await Promise.all(), but I'm curious as to why await* was removed.
答案 0 :(得分：14)
Well, the last revision of the readme before it was removed already mentions everything in that paragraph:
await* and parallelism
In generators, both
yieldandyield*can be used. In async functions, onlyawaitis allowed. The direct analogoue ofyield*does not make sense in async functions because it would need to repeatedly await the inner operation, but does not know what value to pass into each await (foryield*, it just passes in undefined because iterators do not accept incoming values).It has been suggested that the syntax could be reused for different semantics - sugar for
Promise.all. This would accept a value that is an array of Promises, and would (asynchronously) return an array of values returned by the promises. This is expected to be one of the most common Promise-related oprerations that would not yet have syntax sugar after the core of this proposal is available.
So it's no direct analogue to yield* as one might expect, it doesn't really make sense, it was only a suggestion but never really included in the spec proposal.
The consensus was that there is no reason to introduce more syntactical sugar than necessary, calling Promise.all is not much of a difference.
You can check out the discussions in issue 8 or issue 29.
Finally, proposals for mightier weapons (parallelism) are still under way. Check out async iteration, async generators and observables. There might be some that could use an await* keyword much better than for simple arrays of promises.
The async/await proposal is minimal and only introduces the necessary primitives. There is no bikeshedding about possible extensions, which should be discussed separately.