"asking await" syntax proposal

Here’s one point against, though I guess it would be mitigated by nice compiler errors:

Including a ? in the await syntax suggests that the ?-ness can be delayed. This is because the ? isn’t “bound” to the await, since await is a keyword (reserved identifier) and ? is an operator.

Another point is that the cancellation doesn’t appear in the wrapped type at all. In fact, the cancellation barely appears in impl Future, as it’s not a return state, but rather a “didn’t return” state.

And because the common case is .await?? (that is, await!(_)?), this would likely end up with questions along the line of “why are two ? necessary”, when there’s only one impl Try type involved.

A ? makes cancellation look too much like normal control flow (thus something that can be ignored) than it is, when it’s really another unwinding mechanism opted into with async.

3 Likes

And actually it can, e.g. let f = future(); f await?;

Here await is bound to ?, and is a modifier of ? operator.

Thinking in terms of cancellation is incorrect and instead we should think in terms of continuation.

Here, each ? operator occurrence indicates that the forthcoming code is a continuation in case if preceding operation was successful:

  • For Try trait the success is Result::Ok
  • For Future trait the success is Poll::Ready

How we get this success is implementation detail which is irrelevant for continuation.

There's no . operator in my proposal and the common case is await??, therefore it's not so easy to say that it's the await!(_)? or something different, as well as it's not so easy to say that there's only Try type involved.

We might think about ? as about continuation flow which shouldn't be intrusive, since we don't interested in it in most of cases. Nevertheless, I don't think that await? construct is too implicit.


I agree that there would be tradeoffs in cases you described.

We should teach users:

  • To perceive await as a modifier of ? construct
  • To think in terms of continuation instead of cancellation
  • To not associate ? only with Try trait
  • To understand what is continuation flow

But I still don't think that these tradeoffs are worse than tradeoffs of .await syntax

Not what he meant, he meant seperating await and ? because people will see ? in other contexts and assume that it isn't attached to await.

I think you missed the point. The dot wasn't relevant to his argument. He also showed the macro version because that's what was being used in nightly. Finally there is only one impl Try type, and since ? is associared with Try it seems confusing to have a mismatch of 2 ? and 1 Try.

He's not saying that await? is too implicit, but that it sends the wrong message.

1 Like

As I said:

So, what's the point in repeating the same arguments again?

From your wording of your last reply, it looked like you misunderstood what @CAD97 was saying, so I was clarifying. But nothing more. I was not arguing with your points, or making any new arguments.

Okay, the following version wouldn’t have such tradeoffs:

2019-06-09-081255

Here I’ve replaced await and try with ready and ok, because these keywords reads naturally with questionmark, and they corresponds to expected enum variant which makes them easier to reason about.

Changing ? to ok? also might have sense, since ? operator is too easy to apply and e.g. I caught myself that I use it in places where .unwrap() would be fine as well.

Also, I’ve done ?ok? replacement on my Rust pet project and it don’t looks bad, even looks like it helps to visually identify more important method calls as usually they returns Try implementation.


However, it’ll require a new edition, and I’m not sure if it worth it.

What do you think?

As has been noted repeatedly, this issue has already been decided for Rust. Thus this proposal is months too late.

You will have to fork rustc and create your own derivative language (that no one else will use) if you want to test your proposal.

3 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.