A final proposal for await syntax

[Cazadorro]

Wow, I thought this was a joke too. Don’t do this, note this will not work for us with US keyboards, we don’t have US international layouts in the US generally without requiring the user to configure something special IE physically changing the layout of our keyboards. None of the suggestions worked for me that would be simple, a lot of keyboards in the US don’t have altgr (which is often NOT the right alt key) and on laptops its even worse. Alt + 1 doesn’t work on a standard US keyboard on either side, alt + ctrl doesn’t work for either side, and often corresponds to odd shortcuts. Indeed the only way I was able to type ¡ was with ALT + 173 only on the numpad (or using another number code).

Note I have a full five US layout keyboards all different where there was no other way to type out ¡ with out ALT + 173 only on the numpad, on linux It gave even stranger results when I tried to do ALT + 1 (not a random symbol, but printed (arg:1) in terminal [didn’t matter the side that alt was on], and in IDEs it selected weird things).

It is also available using a standard US keyboard by switching to the US-International keyboard layout.

READ THIS! and please stop suggesting this! Basically anything that isn’t just shown on a standard US keyboard is not going to be easy to type for standard US keyboards, and as you’ve seen its even worse for non US keyboard layouts.

[dekellum]

Don’t do this […] please stop suggesting this!

¡If only I knew enough of compiler internals even to prototype it!

Fear not. There is rumor of compose software for Windows and any real editor should be extendable to enter ¡await with minimal contortions.

Okay, so I’m a typography nerd and just like how it looks. You’ve outed me. But this topic is about language design and syntax.

If ASCII is essential, the main arguments remain for @await, @wait, or #await as a strict improvement over the current .await, which will be confused as field access.

[josh]

I made a particular function too slow because three things that were supposed to happen in parallel happened one after the other, again because I just took the convenient route of .await without thinking about it.

With my language team hat on: I find this argument really compelling and worth exploring more.

What would code that awaits multiple futures in parallel (rather than in series) typically look like?

If we want to make it easy to await multiple futures in parallel (and in particular, not await a future until the function can’t proceed without the result), what syntax could/should we provide to do that?

EDIT: just caught up with the rest of the thread, and read the notes about “defer”. That seems to largely address the issue, and I like that there’s enough room to experiment with higher-level structures in the crate ecosystem.

[nikomatsakis]

I just wanted to note that I created a dedicated thread for experience reports – I’m paricularly interested in that sort of feedback, so I thought it’d be good to collect it specially.

[nikomatsakis]

EDIT: just caught up with the rest of the thread, and read the notes about “defer”. That seems to largely address the issue, and I like that there’s enough room to experiment with higher-level structures in the crate ecosystem.

In particular, I personally would like a combinator like join or something that works like so:

let ((a, b), c) = future_a
  .join(future_b)
  .join(future_c)
  .await;

You could trivially build this on the join function. The nested tuples aren’t ideal of course, but it scales to arbitrary numbers. But that’s I guess more of a “futures library” discussion than anything.

[KSXGitHub]

So I just saw a tweet that shows a piece of code that uses .await today and I find that that .await part is not only barely visible, it is also completely indistinguishable from method calls. And this is from a code block that has syntax highlighting.

One of the impressions I have about Rust is that it forces you to explicitly perform operation that are expensive and/or time-consuming (for instance, you must explicitly call .clone() to clone an object, unlike C++). And in my opinion, that is a good thing.

Regarding await, while I do not consider it expensive, it can potentially be time-consuming (the program have to wait for the future). Having an await operator that is indistinguishable from field access might encourage programmer to write code that unnecessarily awaits independent futures sequentially:

get_future_1().await + get_future_2().await

while the correct (more performant) code should be:

let (a, b) = get_future_1().join(get_future_2()).await;
a + b

I don't know how can Rust make the "correct (more performant) code" easier to write and read, but I think Rust should make the "wrong code" more explicit by making await operator more visible. So that whenever I use await twice or more, the source code will scream to my face that "Hey, you have 2 awaits! Care to join them together?".

_{Ironically, this also rules out postfix sigil (one that I supported) as it is even more subtle than dot-await Actually, I take that back, because since I find ? postfix quite noticeable, I think @ postfix must be visible as well}

[nikomatsakis]

Is there any plans on how or why .await is supposed to interact with type deduction?

We had discussed whether it should “auto-deref” or not. At present it does not and it’s not clear that one would ever want it to – in particular, it consumes the thing being awaited, and that would only work for Box<T>, which implements future anyway. But it’d be nice to retain the option in the future (I expect the . operator to generally “auto-deref”).

Methods currently error on an uninferred type variable, it’s true, but that’s largely an implementation defect. If we improve rustc’s inference algorithm, I think I would prefer for type-checking to continue and only error if we indeed cannot figure out what method is being invoked. In general, we do not insert an auto-deref unless there is no possible resolution for the method at a given level.

So, if we applied the same logic to futures, it ought to be forwards compatible with our current behavior. Basically, all cases where an auto-deref might’ve been an option would currently error, so we could add it later (and, because we have no DerefMove-like trait, I don’t believe any such cases presently exist, but I could be overlooking something and I’d like to know if so). =)

[josh]

I find that that .await part is not only barely visible, it is also completely indistinguishable from method calls. And this is from a code block that has syntax highlighting.

That looks like syntax highlighting that hasn’t been updated to know about the await (or async) keyword. await should use the same color as let and fn and use do.

[josh]

The nested tuples aren’t ideal of course

That seems easily fixed with a trait; not hard to make a join of Future<Item=(A, B)> and Future<Item=C> produce Future<Item=(A, B, C).

On the other hand, I think I’d also want a syntactically lightweight mechanism that allows code like this:

baz(foo().await, bar().await);

to be automatically transformed to join the awaits because they don’t depend on each other.

[HeroicKatora]

We had discussed whether it should “auto-deref” or not. At present it does not and it’s not clear that one would ever want it to – in particular, it consumes the thing being awaited, and that would only work for Box<T> , which implements future anyway. But it’d be nice to retain the option in the future (I expect the . operator to generally “auto-deref”).

This is not about auto-deref. This is about type inference. In the code example, the generic argument X for Foo<X> needs to be inferred. Only Foo<u8> implements Future and thus allows application of .await. In the current version, this type argument is thus inferred to u8 and .await can be applied. The question is then if we can rely on this behaviour and what is done to ensure that this will stay consistent across language versions. Specifically since the reason the current code enables this is the hidden, eventual call to poll_with_tls (or something similar) is called directly on the argument of the defacto-macro, and it requires impl Future.

[nikomatsakis]

I see, thanks for clarifying. That situation is actually simpler than what I thought you were asking about. The short answer is that, for better or worse, we do the same sort of deduction for methods, as you can see in this example here:

struct Foo<X> { x: X }
trait MyTrait: Sized {
    fn my_method(self) { }
}
impl MyTrait for Foo<u8> {
    
}
impl<X> Foo<X> {
    fn new() -> Self { panic!() }
}
fn foo() {
    Foo::new().my_method();
}
fn main() { }

If we ever adopt the fields-in-traits RFC (as I hope we do at some point), I presume we would use the same basic logic there too.

At present, the compiler is sometimes conservative when Self is fully unknown, but it is willing to infer other trait parameters on the basis of the set of existing impls. In this case, X is unknown in the trait, but Self is at least partially known, and that’s enough to narrow things down to 1 impl.

[HeroicKatora]

The short answer is that, for better or worse, we do the same sort of deduction for methods, as you can see in this example here:

So it really does behave like a method then

[KSXGitHub]

That looks like syntax highlighting that hasn’t been updated to know about the await (or async) keyword. await should use the same color as let and fn and use do.

It shouldn’t have required syntax highlighting in the first place. I want to read a raw piece of source code on my browser, Notepad, git diff, or via cat without overlooking a crucial piece of information.

[Pauan]

In particular, I personally would like a combinator like join or something that works like so

Until very recently, join was indeed a method call, not a function.

Right now we have the join and try_join functions, and also the join! and try_join! macros.

So it makes sense to me that we should have join and try_join methods as well.

If anybody feels strongly about this, they should create an issue on the futures repo.

[kjeremy]

That looks like syntax highlighting that hasn’t been updated to know about the await (or async) keyword. await should use the same color as let and fn and use do.

Relying on syntax highlighting is a huge red flag for me. I should be able to open up rust code in something like notepad or cat from a terminal and quickly be able to see what’s going on.

[RustyYato]

That seems easily fixed with a trait; not hard to make a join of Future<Item=(A, B)> and Future<Item=C> produce Future<Item=(A, B, C) .

But what about if you want to join 4 futures, how about 5 or 6? This could go on an on, and without variadic generics, we can’t do any better than a macro or nested tuples. Now a macro could easily convert from nested tuples to the flattened version, and we can do that now.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=affb8005005ac1caa25fe83884dced7d

On the other hand, I think I’d also want a syntactically lightweight mechanism that allows code like this:

baz(foo().await, bar().await);

to be automatically transformed to join the awaits because they don’t depend on each other.

I don’t think this would be a good idea, it seems to brittle.

[scottmcm]

I made a particular function too slow because three things that were supposed to happen in parallel happened one after the other, again because I just took the convenient route of .await without thinking about it.

What would code that awaits multiple futures in parallel (rather than in series) typically look like?

In C#, I yesterday (literally – I just checked) gave the “you should do that in parallel” feedback for this code (domain object names obfuscated, but the code is otherwise untouched):

var sprockets = await this.ExtractContent<SprocketContent>(SprocketPath);
var widgets = await this.ExtractContent<WidgetContent>(WidgetPath);
var spanners = await this.ExtractContent<SpannerContent>(SpannerPath);

So I think prefix await isn’t immune to “just await without thinking about it” either.

That said, it’s a pain in C# to do this differently, because Task.WhenAll only supports the homogeneous case. If I understand How will Promise.all be implemented? correctly, then this will be way better in Rust – whether prefix or postfix – as it could be

let (sprockets, widgets, spanners) = join!(
    self.extract_content::<SprocketContent>(SPROCKET_PATH),
    self.extract_content::<WidgetContent>(WIDGET_PATH),
    self.extract_content::<SpannerContent>(SPANNER_PATH),
).await;

That looks like syntax highlighting that hasn’t been updated to know about the await (or async) keyword. await should use the same color as let and fn and use do.

+1, and I wonder if that actually makes .await less noticeable than with no highlighting, as one’s brain starts relying on the colours for mental parsing shortcuts.

[andylokandy]

I am suprised that no one is talking about UCS macro in this thread. I’ve noticed that a large part of community in reddit has reached consensus on postfix macro fashion powered by unified call syntax + prefix madatory.

Blog post and discussions

Besides, there is a unofficial survey, which also shows favors of postfix macro among all proposals (the one with biggest proportion of ‘perfect’ option).

In brief, with UCS-macro, postfix await will be not magical; it’ll be trival, orthogonal, user definable (except that await is a keyword). And the most importantly, it completes the chaining story in rust so that we don’t need ? for Try, magical await field access for async and new magical syntax for something may appear in the future. (ps: ? syntax is cute, I love it)

[josh]

It doesn’t require syntax highlighting. And if you don’t have syntax highlighting at all, I think it still reads just fine.

Having some syntax highlighting that is incomplete (and doesn’t know about all keywords) is harmful: highlighting some keywords gives a signal that keywords will be highlighted, making un-highlighted keywords easier to miss.

[Pauan]

I am suprised that no one is talking about UCS macro in this thread.

People aren’t talking about it because it’s already been discussed to death (months ago), and rejected by the Rust team (for await). Perhaps postfix macros will be implemented in the future, but not right now.