A final proposal for await syntax

Note that the criticism of .await is fundamentally different. When the await keyword was introduced other other languages, you did not see people complain that existing syntax in the language was overloaded to mean different things.

To make it crystal clear, Rust already has

  • expr.ident: this a field access
  • expr.ident(): it is a method call

The new proposed expr.await syntax clashes with the field access syntax. This is seen as a problem by people like me. Others think it's fine because they weight the ability to do expr.await? higher. This is basically what the discussion is about.

9 Likes

Then why don't we innovate completely: use the postfix sigil.

then is not a keyword in rust and if ... then ... is not possible in rust. Thy syntax is if a == b { do_this(); }. A list of keywords and reserved keywords can be found here.

4 Likes

Right, I am confused for a moment.

Personally, I think a sigil is a good idea. But the Rust team said this:

Other choices (like “ expression@await ” or “ expression#await ”) suffer from too much from the “line noise” problem and we strongly prefer to avoid introducing new meanings to punctuation characters for this purpose. For that reason, we discussed expression await as the primarily alternative to expression.await .

Essentially, they want to avoid adding new syntax as much as possible. They think that repurposing existing syntax is better than creating whole new syntax.

You can disagree with that if you like, but that is the Rust team's position.

There is a very good summary of the most common suggestions (and the Rust team's perspective on them): https://paper.dropbox.com/doc/Await-Syntax-Write-Up--Ac0thksDVSy3tvoeoAgO8BSnAg-t9NlOSeI4RQ8AINsaSSyJ

All of your suggestions have already been suggested before (many times!). You are not presenting anything new. This debate has been happening for months, with an incredibly large number of ideas suggested:

No matter what the Rust team decides, somebody is going to be unhappy. It may not be perfect, and not everybody is going to agree, but that's simply how life goes. It is literally impossible to please everyone, but a decision must be made.

And they made the decision in the best possible way, taking into account everybody's arguments, and thinking long and hard about this problem.

12 Likes

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.

8 Likes

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.

10 Likes

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)

1 Like

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.

7 Likes

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).

13 Likes

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.

16 Likes

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.

2 Likes

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?

9 Likes

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”.

7 Likes

We (the language team, myself included) are reading your comments and responding to them.

19 Likes

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.

10 Likes

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.

6 Likes
  1. Posting in this thread is exceptionally unlikely to make your voice heard among the din.

  2. 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".

19 Likes

In addition, future.await is employed by the most languages according to this:

2 Likes

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.)

2 Likes