On why await shouldn't be a method

[Pauan]

@zackw

.await() could be a real trait method in a hypothetical future version of the language (that has a bunch of features that may or may not ever get added because some of them might be more trouble than they’re worth).

No, it really cannot. Because shallow coroutines are a fundamental part of the design of async/await (and indirectly, Rust in general, but that's a bigger conversation).

Theoretically, Rust could introduce a completely new system, like Scheme's call-with-current-continuation (or some sort of effect system), and then in that case we could implement await as a method.

But even then, that would be a new system, the old async/await system would still behave in the old way (because of backwards compatibility).

And it seems really weird to suggest that we implement a trait method now (even though it doesn't behave at all like a trait or a method), just because hypothetically 5 years from now we might get some fancy systems that make trait methods possible.

@zackw

In other words: It seems to me as if everyone who is arguing that the await operation is too magical to be a method should like field access-like notation even less .

No, because .await is far less magic. It's just a keyword. It's not any more magic than return or break. It's easy to explain, and easy to understand.

But a trait method involves huge restrictions and/or massive compiler magic to support (and likely completely new features which haven't even been RFC'd yet). It's incredibly difficult to explain, especially with regard to all the restrictions.

@zackw

But I see this as an argument for an effect system or something

I agree, effect systems are very cool. But you seem to be misunderstanding something: the Rust community has been waiting for async/await for literally years.

There is a strong pressure from important projects that want to use async/await, and there are deadlines to meet.

We're not going to wait for 5 years to debate a complex effect system and then implement async/await.

And that's assuming that an effect system would even be accepted (it likely wouldn't, due to the massive ramifications throughout the entire language).

@zackw

I am not super happy with ? for other reasons (related to my distaste for implicit return in general), but it’s definitely not a function call, because it introduces a branch into the visible CFG. You have to be aware that every instance of ? is a point where the surrounding function might return to its caller, to understand what the surrounding function does. That’s not the case with await .

That's not true. The .await operator inserts a loop and creates a branch in the state machine. A method cannot do that.

By its very nature it must affect the control flow, because of the fact that it needs to yield.

This is not just some implementation detail, it's a fundamental part of how async/await works (just like how return is a fundamental part of how ? works).

It's also not the same as synchronous blocking, because .await actually transforms the control flow of the async function (unlike synchronous blocking, which is just an ordinary function call, which doesn't affect the caller).