Why were the alternatives considered discarded?

[LeszekSwirski]

I see a list of alternatives considered, but no discussion of pros/cons or reasons why these are alternatives and not the chosen approach. I'm particularly interested why a syntax approach was discarded, in particular a const await that could then avoid the intermediate object, like

const await {
  shape = getShape(),
  color = getColor()
};

[acutmore]

Hi @LeszekSwirski,

At least during my time being involved with TC39 it has been common feedback to avoid introducing new syntax unless there is a very compelling reason. While I do believe this is a useful API, my (perhaps wrong) assumption was that it wouldn't meet the threshold for syntax. We did also discuss this proposal in the context of Iterator.zipKeyed and at the time there was agreement on aligning this proposal with that due to their similar type shape.

I really like being able to avoid the intermediate object here. It is similar to my desire for #{ x: 1, y: 2 } syntax in Composites to avoid the cost of Composite({ x: 1, y: 2 }). Especially as I imagine code using Composites will want to create lots of them. Whereas co-ordinating multiple async requests may more likely be I/O bound code, where the allocation is less problematic.

There is https://github.com/tc39/proposal-await.ops where we could explore a syntax solution in addition or instead of this proposal. I am also interested in the inspiration from Swift: https://github.com/tc39/proposal-await-dictionary?tab=readme-ov-file#dedicated-syntax, though I suspect the push back on there is the difficulty in seeing the exact positions that will yield. Your syntax sketch is more scoped, and I can imagine that having a better chance of progressing.

I will update my plenary slides to make an explicit point of discussing this, as I am more than happy to explore this space if it appears to have legs.

[LeszekSwirski]

That's reasonable, and it's all stuff worth adding to the README -- my personal preference would be new syntax for this, both as a language user (I don't want to type the names twice) and as an implementer (my personal opinion, we haven't discussed this inside V8 yet for a team-wide position), but either way it's inside a tradeoff space that merits enumeration.