For those who are writing it in: I have not included the .. suffix as an option on the poll because this is already the range operator. And because it is possible for a type to implement both the Range and Future traits it is genuinely ambiguous.
1 Like
I can very easily imagine that the approvals for the prefix macro solution are effectively many peopleās ānot ideal but acceptableā middle-ground.
This is a case where ranked choices would be very helpful.
5 Likes
No, ... only works as a pattern. It doesnāt work to create ranges. Also ranges are types, not traits.
Sure. What I called Ā«magicĀ» is whatās referred as Ā« Order of Operations SolutionĀ» in the lang team write-up. In the summary, I used the example let str_response = await http::get(url)?.to_string();.
The Ā«obvious orderĀ» is the naive way of thinking about the keyword, where you need parenthesis to make it work : let str_response = (await http::get(url))?.to_string();
This is a case where ranked choices would be very helpful.
It won't be that helpful, because you know, āno ranked voting electoral system can convert the ranked preferences of individuals into a community-wide rankingā ;).
Fortunately, this decision will not be made by votes, and these polls are just that: polls, so it's not that bad 
Yes. As you can see despite having higher percentage of people who said the macro style "looks ok" is has fewer people who selected it as their favorite that the postfix macro style.
Seconded
Sorry in the above post I wrote .. inside of quotation marks but for some reason that renders as three dots inside quotation marks. Like so: ".." (I only typed two dots in there). Weird.
Google forms can only handle so much.
Thatās weird. Either way, ranges are a set of types, not traits.
One other interesting data point: Reading between the lines in peopleās responses, if the Postfix macro rfc were to land and they were to become a thing in Rust the number of people who would support that style of syntax would go up by 10%. (Maybe more, as it might change the mind of some people who just clicked ālooks badā) That would be sufficient for it to take the lead in %approval. (It already is in the lead for % favorite)
1 Like
This is also neglecting the relevance of other problems tied to this syntax. For instance, in addition to the ? problem, there is also the for loop problem. As withoutboats has written, the await keyword is a better fit than async for for loops.
Just for kicks, letās see what happens if we try to use await as an outfix macro in for loops:
for await!(foo) in stream { ... }
Hm. This looks like a pattern macro, which is misleading as the await! is part of the for loop rather than the pattern.
1 Like
What about await![] and await!{}? They come for free alongside await!(), as I understand it, but I currently do not recall seeing any examples use either. I feel that careful use of them could decently improve readability, making it easier to tell which parentheses match.
How would you chain awaits?
let x = future_wrapping_another_future await await;
What about the Strousupās rule ?
From where I stand as a casual developer with something like 20-30K LOC of rust written, I feel that the try!-? migration went very well. Yes there was some discussion around the topic. But the final design was resolved rather quickly, since everyone was used to error handling using try!
7 Likes
It took a bit of work to migrate away from try!(). I've made PR's to a bunch of projects, and manually updated StackOverflow answers.
However, if postfix macros become a thing, with await!(foo) naturally becoming equivalent of foo.await!(), I think that would be fine. It wouldn't be deprecation, but extra flexibility/orthogonal syntax choice.
1 Like
Personally, I think await for _ in _ works for any potential syntax that uses the keyword await. (Potentially even if await is de-keyworded via a contextual keyword, but I've not thought much about that.) Any solution that puts await on the other side of for (except maybe for.await) will be human-ambiguous to the await being on the pattern, not the for.
Thus I believe that the streams question, while interesting for consistency with the main await syntax, shouldn't limit the options. (Unless some team member comes up with the perfect "have your cake and eat it" solution here, but I think we've explored the problem space enough that it probably doesn't exist this time.)
1 Like
Current standings. (The poll is still open)
From most to least approved:
Macro style syntax 65.6% approve 29.4% favorate 2.1% itās complicated 32.8 dislike
Keyword
59.5% approve
26.5% favorate
0.7% itās complicated
38% dislike
Postfix macro style syntax
54.0% approve
36.0% favorate
2.9% itās complicated
43.1% dislike
Keyword with braces 40% approve 11.8% favorate 60% dislike
# Sigil
39.4% approve
21.3% favorate
60.5% dislike
@ Sigil
37.2% approve
18.4% favorate
62.8% dislike
Function style syntax 34.3% approve 8.1% favorate 65.7% dislike
Keyword with optional parenthsis 34.3% approve 9.6% favorate 65.7% dislike
Method call style syntax 33.6% approve 14.7% favorate 66.3% dislike
Field! access style syntax 33.6% approve 7.3% favorate 66.4% dislike
keyword with ? specal case 30.7% approve 13.2% favorate 69.3% dislike
Postfix space syntax 28.5% approve 13.2% favorate 71.5% dislike
Sigil + await suffix 24.8% approve 5.9% favorate 75.2% dislike
Field access style syntax 21.2% approve 8% favorate 78.8% dislike
Keyword with additional try keyword 14.5 % approve no favorates 85.5% dislike
.. Sigil + await
13.8% approve
86.2% dislike
Observations
- Keyword has risen to second place.
- Function style syntax has dropped a lot.
- Several of the less popular items have continued to loose ground to the more popular options.
2 Likes
Actually it was quite cumbersome, a lot of my code had replaced try! with a custom tryl! which logs errors, and the ? syntax still doesnāt fit in with that way of doing things, but now probably will confused any new developers coming in.