I think most participants here appreciate that. So perhaps it can be more clearly articulated as the .word visual pattern is currently used primarily for field access or a couple of traits implemented on fields (Deref, etc). People are concerned about a lot of things, consistency, ergonomics, teachability/learnability, etc.
That is true, but I think some people are actually also just trying avoid confusion (perhaps just with a different expectation of mastery or size of mental model - but I know this is a very fuzzy concept anyway).
To the latter part of your post, if await, specifically in .keyword form was already part of the RFC I humbly retract the comment you were replying to, but I guess what I was trying to say is that if it wasn't envisioned when the RFC was accepted, and the scope naturally crept to land on this pattern a lot of the concerned community members might be more comfortable with the decision if it was illustrated somehow that the change to this (visual?) pattern was also carefully considered (and I'm not saying that it wasn't, maybe it can just be pointed out or written up).
We all eagerly anticipate async/await and it is definitely not in anyone's interest to delay it unnecessarily, but asserting that the reason for questioning this design choice might be motivated by trying to impede the adoption of the design choice isn't fair - feedback was solicited, all of these suggestions can be comfortably ignored with no repercussion.
Lastly, we can keep 100% of what @withoutboats proposed the final syntax should be (postfix/keyword) and change the chosen sigil to visually differentiate it from existing language syntax and I think a lot of the concern will be eased. Again - not saying this with the intent to frustrate or impede the process, but merely providing feedback.
Would you all, despite what must be considerable fatigue on this subject, and/or the
prior poll
authors (@tkaitchuck) consider another round of polling? The main deciders have been thinking of this syntax question for over a year, but if we, in good faith, imagine that there is a meeting tomorrow where later considerations and new ideas will be seriously considered, then this might be the last chance for a final poll? It might also be too late, but I’d hope the committee might remain open to input, given other delays.
Comparing the polls questions, I would suggest the following alternatives:
prefix macro - await!(future)?
prefix keyword - (await future)?
postfix .operator - future.await?
postfix .OPERATOR - future.AWAIT? (not a field)
postfix @operator - future@wait?
Here I’m trying to balance popular results in prior polls, with some new input. You’ll notice a lack of a postbang ¡ sigil in this list, given feedback. Though I have my own biases of course, I otherwise defer to your prior poll design and execution experience and will certainly participate regardless.
To what end? I will ignore the results of the poll in any case because our process is based on team consensus where we consider good arguments and new information, not popularity. Moreover, I think there's little a new poll would add.
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.
While I agree with this, as you know, the summary of the main thread was by design a subset, and not maintained. So end users, who come into these discussions at a major disadvantage, don't have a clear set of values/goals to evaluate a new idea against, or even find if that idea has been previously raised.
Back to the topic of a new poll. Could we share notes and make a poll more scientific at least? I certainly agree that poll design is difficult. One new idea, I have on that since my last comment, would be to try and engage people on the URLO (which might be closer to prospective and newer users?) and have them rate the Fuchsia inspired syntax examples that several people did earlier and I did a bunch more recently.
Yes, and the lack of both syntax doesn't help with this issue.
Currently it is not possible to say that "I am using prefix here but postfix would be better" and vice-versa, so that we could see the potential upsides and downsides of each.
