Given that it has come up several times, and that I discussed it in some of these threads myself, I think this is worth mentioning explicitly:
.keyword syntax for keywords other than
await (for instance,
.match) will not happen without a separate RFC, separate discussion, and separate rationale.
.await would serve as input into that, but not as ironclad “we should definitely do this” precedent. In particular, I’m treating the decision on
.await and the decision on
.keyword as orthogonal.
I hope that helps disentangle the two concepts somewhat.
Apart from that, I’d like to observe an issue that applies to this kind of discussion, when everyone is arguing from closely-held values and requirements that conflict. I feel that many, many people are talking past each other here. Responding to “X has advantage Y” with “but A has advantage B” doesn’t do anything to establish common ground, and when Y and B involve closely held values that can create a great deal of acrimony and frustration. Such responses make it feel like the person responding and proposing the new solution doesn’t care about (or isn’t considering) the values previously expressed.
In any discussion like this (and I doubt this will be the last feature prompting widespread debate), I think it’s worth explicitly acknowledging that people care about different things, that we’re in the domain of satisficing solutions, that it’s unlikely any proposed solution is going to make everyone happy, and that at best we’re looking for (and not finding) solutions that better satisfice everyone. In that vein, anyone proposing additional solutions, or arguing for one solution over another, should be looking not just at advantages, but also how well any given solution satisfices all the values and requirements in play here, not just one’s own values and requirements.