Yet another async/await poll

@HeroicKatora

It’s a fair criticism, though unfortunately it’s a bit late to change the poll. Hopefully future readers will read our discussion before voting.

@tkaitchuck

As I wrote in the earlier message, implementing one variant does not mean the second will be 100% implemented as well, it will be left up to future discussions, after stabilization of one of the options has happened. Maybe I’ve used not the best wording, but hopefully it will not influence results too much.

1 Like

I’m not issuing a proposal to change any existing syntax. I’m just pointing out that the question phrasing above is extremely loaded and implicitly is forcing respondents to agree to a controversial new proposal that hasn’t even had an RFC yet.

2 Likes

(I’m not going to partake in this poll or any other poll on await. I don’t think they are useful, they are conducted in unscientific manners. They would certainly not be fit for academic papers but neither for fora requiring lesser standards either. Flaws include, but are not limited to: 1) No randomization of questions, 2) Biased formulations presuming the future, 3) Small selection of options – and no ability to select multiple choices, 4) Not using a realistic setting to ask questions (e.g. no snippets and no syntax highlighting, 5) Questions are not done first in an environment where the user has already been loaded with opinions by others, 6) No ability for people to elaborate and give their reasoning after conducting the poll – the last one being essential to have any value for me)

To remove any possibility of doubts as to what syntaxes I consider most appropriate, here are some syntaxes from most to least appropriate:

  1. fut.await?
  2. some sigil (e.g. fut#?)
  3. fut.await()?
  4. fut.await!()?
  5. fut await?
  6. (await fut)?
  7. await fut?
  8. await? fut

That is, assumptions that prefix await is considered viable by me is mistaken.

5 Likes

Realistically how will fut.await be generalized?

One of the reasons I like await fut despite wanting a postfix variant is it’s the most simple candidate and leaves things open for what the community can mostly agree on. Right now people seem very divided on using the dot operator for control flow that we see in fut.await

2 Likes

I’m not sure if I’d like generalization of .keyword or some other prefix-postifx keyword generalization. I never found myself in situation where I’d really need foo.match {}, and syntax like foo.return or true.if {} would be too weird.

I do think generalization of await!(foo) to foo.await!() would be nice. I had a need for a try!()-like macros that behave differently from ?. I’d love to have value.my_try!(). But it doesn’t seem that postfix macro is an option.

And to be honest, eventually I’d probably get tired of writing the extra !() after the await. The plain .await looks odd, but speaks to my laziness :wink:

6 Likes

Strongly agree with this, if accepting .await opens the door for the above other cases then I’m strongly against it.

Postfix macros do seem to have lots of other uses too.

This. And once your brain adjusts the code does look nice.

One case that occurs to me is something like

try { ... }.match { ... }

Otherwise, you end up with, somewhat awkwardly:

match try { ... } { ... }

Of course, if some kind of catch is added to the language, this becomes somewhat redundant.

I think the other angle to look at it is, instead of trying to figure out how .keyword could apply to existing keywords, instead consider that some future keyword operations might also benefit from postfix chaining.

1 Like

Of course this makes sense, however I feel that await is the wrong place to start this. It should be an RFC in its own right.

1 Like

What should be an RFC in its own right? That future language additions might choose to use .keyword syntax when appropriate? This is inherently something that has to start somewhere unless you’re aiming for fully generalized keyword operation chaining as syntax sugar for existing leading keywords.

1 Like

Pretty much this yes, open the door formally for a change to the language regarding field access to allow for .keyword, starting with await.

This isn’t field access, so there is no language change being proposed affecting field access. Field access is .identifier when not followed by (argument list). This is .keyword. I understand that some people are concerned that beginners unfamiliar with a particular keyword might mistake it for an identifier, but that doesn’t change the fact that it’s an entirely independent syntactic construction. Pretending otherwise seems more likely to invite the very confusion people are seeking to prevent.

The use of .keyword in the particular context of .await has already been amply considered. async/await can’t be stabilized without resolving the syntax question. There really is no reason to try to legislate under a new RFC whether a particular design choice that has already been considered as part of an existing RFC should be permitted unless the goal is simply to impede the adoption of that design choice.

3 Likes

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.

1 Like

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.

Thanks for your consideration.

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.

I have elaborated on this in Yet another async/await poll.

9 Likes

Well perhaps others might be interested? :slight_smile:

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.

7 Likes

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.

1 Like

I feel your pain. Yes, it’s painful to keep up with the myriad discussions.

To what end? Please read the opening post of A final proposal for await syntax and the dates listed in it.

2 Likes

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.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.