Please stop flogging a dead horse.
See the last part of postfix .await is implemented in 1.37. That could be reversed, but IMO .await is now a fait accompli.
Edit for clarification: This comment was directed at everyone in this thread who wishes to persist at the Sisyphean task of convincing the language team to reverse their oft- and well-explained decision.
While people will find problems with all the suggested approaches, I think it is a mistake to say that the problem are the same and that any solution is "good enough" then.
It's my clear impression that people who criticize the await expr syntax does so because of the inconvenience it will bring to error handling with ?. They don't like how (await expr)? looks and they argue that it will make it more annoying to write longer chains of expressions. I don't think people from that camp have argued that await expr would be wrong -- merely that it would be inconvenient.
On the other hand, people who criticize the .await syntax does so because they see it as a wrong use of existing syntax. Note how this is very different from being it being inconvenient.
In fact, I will say that I also find expr.await? is easier to write than (await expr)?, but I still see it as a mistake to mix different things into the same syntax in this way. Perhaps a silly example to illustrate what I mean by mixing things that shouldn't be mixed: should let s: &str = 123 be legal just because it's easier and faster to write than let s: &str = "123"? No, it would add strange magic behavior to the language.
Of course, I disagree with that (btw, how can I talk to this "Rust team"?).
Avoiding new syntax only makes sense when the feature is not something drastically different, but async seems to transform an intuitive control flow into something very different. It must not be the same syntax.
Beside, how can they introduce ? postfix for result/option but not a sigil symbol for async!
But in this case, it is more than just "somebody". (It has also become a meme at this point)
That is why I must make my voice heard. (I'm not sure if you were replying to me though)
Have folks with screen readers been consulted? These kind of seem like shots in the dark. Having talked with a handful of blind programmers over the years, they haven't seemed to care about grammatically correct English being read at them, but rather something that precisely and tersely conveys the code and its context. Excessive deliminiters are often the enemy of this goal. Scala has official accessibility mode that's worth looking at.
By engaging in the discussion threads (like this one, and the previous one, and the previous one before that, and the previous one before that, and the RFC before that...)
The Rust team doesn't talk much, but they do carefully read the discussions.
There have been so many discussion threads about this, continuing for months and months ad infinitum. There's been many opportunities in the past to discuss this.
The time to make your voice heard was months ago, when the discussions were happening. That time is not now. The discussions have already happened, and the decision has been made.
In addition, as I said, all of your suggestions have already been suggested many times, during the time of the discussions (which took place months ago).
When dealing with a large project (like Rust), there are processes that are followed. There are deadlines, timelines, and many many many people involved.
Making decisions is not easy, reversing decisions is not easy, and repeating the same arguments over and over again costs everybody a huge amount of time (and stress).
Rust is not a democracy. Things are not decided by popular vote. Rust is also not dictated by Reddit (who are a minority within the Rust community).
Adding more voices will not change anything. Repeating existing arguments will not change anything.
The only way to change things at this point is to present new arguments that have not been heard before (but that's unlikely, since essentially every possible argument has already been made).
Thanks for asking the right question :).
I have spoken to a braille line and screen reader user and they were not thrilled about the screen reader mode. They described that in this mode, they would have to constantly map the spoken word (e.g. type a context bar) to what they would need to write and change ([A: Bar]) in their head. They just vastly prefer using a braille line anyways for dense code like this.
As always, disability is diverse, so this is just one opinion and shouldn't be generalized.
I don’t buy any of this. This comes up every time a feature change happens - people don’t know when the right time to discuss it is, and then when they hear the decision the only thing they do know is that it’s too late, so they scramble to be heard.
That isn’t their fault, and it’s up to the rust team to fix it.
I don't think that's true.
It's been discussed for many months on Reddit. It's been discussed on the official RFC, it's been discussed on the tracking issue, it's been mentioned on "This Week in Rust", it's been discussed on IRLO, it's been discussed on blog posts, it's been discussed literally everywhere...
It's been one of the biggest and most visible changes happening to Rust since Rust 1.0. I'm not sure how it's possible for a Rust programmer to not be aware of it (unless you completely ignore all news related to Rust).
RFCs are the official process for making changes to Rust (in fact it is the only way to make changes to Rust), so if you really care about following Rust development, you need to be following the RFCs repo.
How can the Rust team fix it? This feature has been advertised like crazy for months.
If you're late to the discussions, sorry, that's just how life goes. There will always be people who are late to the discussions, should we delay the discussions forever, and never reach a decision?
I disagree with this; all of these threads started recently specifically because the language team released a document soliciting feedback from users. People are not arriving late, they are arriving when invited.
The feedback has continued for ~2 weeks because although there are people raising suggestions, there hasn’t really been any particular answers to many of them. Although I’m certain that the language team is reading comments and taking them into consideration, people will continually post their opinions until someone answers their personal questions/suggestions. Otherwise they simply assume that nobody on the language team read what they said, and so they keep re-raising it for visibility.
Obviously it’s not practical to have the language team answer continuous questions on a forum, but people will always believe that their point specifically warrants a response.
Edit: also note that the merged PR for this syntax specifically states “This new syntax is not final”.
We (the language team, myself included) are reading your comments and responding to them.
No, the Rust team is inviting new arguments (i.e. arguments which haven't been made before), not a rehash of old arguments which have been made dozens of times before.
They made their final decision based on all the existing arguments, so repeating old arguments does not change anything.
The actual discussion threads were these:
(They are linked from the RFC thread)
The official "decide the syntax for await" thread started in January. It received many many hundreds of comments, discussing every possible option and alternative (and discussing pros and cons for all of them).
The final proposal was created after the discussion had died down and no new proposals had been made.
Discussions about new features happens on the RFC threads (and sometimes in the tracking issues). The Governance link on the Rust website makes this clear. So if you're waiting for an invitation on IRLO (or Reddit), you're too late.
I think a lot of this is people just not understanding how the Rust process works. But it's not because Rust does a bad job of explaining it: the Governance link on the Rust website is clear. The RFC repo is clear.
But some people only interact with the Rust community through Reddit, so they get a very skewed idea of how things work.
If you want to be involved in Rust development, you must be involved with the RFC process, since it is the only way that decisions are made in Rust. Browsing IRLO/Reddit is not good enough.
I think the only thing which hasn't been explained very thoroughly is the desire to not use sigils. Everything else has been explained sufficiently, in my opinion.
I’m so sorry; I read this back and it didn’t come across as intended. It definitely was not meant to come across as a complaint/criticism, it was more of an observation on why these threads are still so noisy after the syntax has already been discussed at length by the team.
I meant to say that for any given person whose comments are not specifically addressed, they’ll likely keep commenting until they are - either because they don’t read the whole thread to see that it was already broached, or because they assume that their comment was missed by the people making the decisions.
I definitely didn’t mean to imply that responses are not being made in general! I completely appreciate the time already being taken (by everyone, not only the language team) in replying to as many comments as have been replied to. It must be a huge effort to keep up with reading through comments, given that I imagine this specific topic is causing input from a much wider audience than usual.
Posting in this thread is exceptionally unlikely to make your voice heard among the din.
Volume and repetition are not useful. Restatements of existing information and existing arguments are not useful. New information is useful.
Taking those two points together: threads like this one would be much more productive if each post was a best-effort attempt to make it clear "here's what information I have to offer that has not in any way been considered previously".
The language team has, several times, reconsidered and changed positions when a new option arises that nobody had considered before. As an example, the 2018 module system was not the original version of that system; it was a new possibility discussed and brought forth, seriously debated, revised, and ultimately adopted. These things do happen. But they aren't prompted by the 23rd post of "has anyone considered a postfix sigil". They're prompted by "I've read most of what's been written about this, and while I might have missed something, I don't see any discussion of possibility X at all, and here's precisely why possibility X isn't like any of the options that were already evaluated as part of the current summary document".
In addition, future.await is employed by the most languages according to this:
They absolutely were just shots in the dark. Unfortunately I don't know any such programmers personally, and although I tried to reach out to a particular forum member whom I know to be blind for comment I have not received a response.
If there is at some point an official poll on the syntax proposals, I would like it to include a question on accessibility needs, such as "do you use a screen reader or other accessibility tool for coding, and if so, does this make particular syntax proposals particularly problematic". (That's not a great question as-is, but it demonstrates what I'd want to gain from such a question, I think.)
@Pauan it feel like you are just shutting down new voices with this kind of post. The announcement here: https://boats.gitlab.io/blog/post/await-decision/ explicitly states in the conclusion that “We’ll continue to solicit and consider feedback until the May 23 meeting”, people who are not “insiders” are trying, very loudly, to give the Language Team feedback. @withoutboats’s blog isn’t in the RFC repo, clearly this discussion has graduated into the wider domain, it is a big decision and it affects everyone - even casual users or vocal enthusiasts, it is even drawing long-time lurkers like myself into the discussion.
People are very loudly trying to get a message across that even though they might have nothing new to add, because perhaps there literally isn’t anything new to add, they are not happy with the this decision because a lot of people feel that the proposed syntax adds surprising “magic” to the field access syntax.
Rust is known for it’s ramp-up difficulty and surprising exceptions to common use patterns (as this might turn out to be) just increases the cognitive burden/cognitive load. Some of the discounted syntax proposals are justifiably bad in their own right, but we need to keep in mind that people learn and build mastery in certain ways. Something I’ve always admired about rust is the ability to easily reason about snippets of code and know very precisely what it does. The more magic/exceptional behavior that gets added to the language, the harder that becomes.
Don’t shut people down because they can’t add something new, listen to what they are trying to say, the feedback was solicited.
The problem with this is that Rust isn’t a popularity contest. It’s ultimately the language team’s decision after considering arguments put forth by the community.
A loud din of complaints isn’t an argument. In any fact, opinions against the current direction are more likely to be shared, as when you agree with the direction, there isn’t the “outrage fuel”.
Community opinion is considered somewhat, and in fact has been considered in the lang team’s current position. Boats’ announcement post specifically calls out .await as better than .await() because it is more surprising, thus less likely to lead to incorrect mental models.
But ultimately the decision is the lang team’s on what they believe is best for Rust in the long term, not what the vocal part of the community is least upset about.
I'm certainly not trying to do that!
I am however trying to prevent old arguments from being rehashed.
You also did not quote the next paragraph:
I want to add, however, that the amount of feedback regarding syntax for the await operator has been overwhelming. It has also devolved into a situation in which many commenters propose to reverse previous decisions about the design of async/await on which we have already established firm consensus, or otherwise introduced possibilities we have considered and ruled out of scope for now.
There's a reason the title is "A final proposal for await syntax". Technically the actual final decision will be on May 23rd (as you quoted), but nothing will change about the decision unless new information is given.
And what people (not just myself, but also the Rust team) have been saying, is that loudly saying the same thing over and over again is not helpful.
Contributions are wonderful, but they have to be helpful, not just wasting time with repeating the same thing.
If people care about contributing, they need to follow the official process. That means being involved with the RFCs. There are many good reasons why Rust has an official RFC process.
If people don't care about contributing, that's fine, but then they can't complain when decisions are made without their input.
And they have the right to be unhappy. But the decision isn't going to change just because they're unhappy. It will only change if new information is given.
All of that has been very carefully taken into account by the Rust team. Withoutboat's blog post also goes into a lot of detail about that, and explaining why the Rust team thinks the complexity is justified.
People may not agree, that's fine, but no matter what decision the Rust team makes, there will be a large number of people who disagree. That is simply how people are.
It is not me shutting it down. The Rust team has repeatedly asked people to not repeat old arguments, and this request has consistently been ignored.
Please show some respect for the Rust team's wishes. Violating their simple and reasonable request is a surefire way for them to get overwhelmed, stressed out, and stop engaging with the community. The Rust team are people, people with limited time and energy and willpower.
If you (anyone!) feel strongly about the process, and feel it could be clearer, please feel free to participate as an observer in the meta language working group and the governance working group.
The point of these groups are to analyze the current methodology of the language team’s communication and the governance model respectively to find where things are breaking, and suggest workable action plans to improve them.
This kind of “meta” work isn’t “fun” the way working on a new feature is, and it isn’t as openly trivial to hold and share an opinion as this week’s bikeshed color. But it’s important work, and it’s how we can do better.
@Pauan there is what you say and there is how you are saying it. For the record, I am for the .await syntax, but I feel brow-beaten enough that I will just excuse myself from this thread at this point.