See, now this is exactly my issue with this syntax, I generally expect to be able to "chain" things with the "." notation.

The post does mention that the hypothetical either-postfix-or-prefix-keyword idea would only apply to certain keywords, e.g. keywords that evaluated to non-useless values (which wouldn't include keywords like return, continue, fn, and so on).

You can chain .await, though.

    let n = future_of_future_of_int
        .await
        .await;

Curiously, will there be limitations to where it can be used? Eg, imagine a `foos.iter().map(|f| f.await).collect::<Vec<_>>()`?

That seems crazy, think it'll be possible?

Not as things are currently designed. This is similar to how you can’t use things like the `?` operator, break, return, etc. inside a lambda and expect it to affect the outer function: it doesn’t work because lambdas are treated as their own functions. Personally I think it would be cool to pursue an extension to lambdas that would allow some of those things to work, but I’m not a Rust team member or anything, just an interested observer.

Technically, `?` can work in lambda's if the return value is a `Result` - though it won't work like it's being called as part of a normal loop or whatever. That's largely mitigated by the combinators available on an interator of `Result`s.

So I think we'll just need similar tooling for lambdas - perhaps an `async` modifier for them? That (I think) would lift await stuff up to `?` in terms of lambda support.

Yep, and in fact async lambdas are already a thing on nightly. But, while I may just be nitpicking, `.map(async |f| f.await)` wouldn't do anything useful. Applied to an Iterator of Futures, it would be a no-op, kind of like (since you mentioned `?`) `.map(|x| Ok(x?)). Instead you'd probably want some combinator to turn it into whatever "Iterator but async" trait Rust eventually standardizes on – futures-rs has Stream for this purpose, but std doesn't have anything yet. That trait would have its own collect() method which would return a Future<Output=Vec<T>>, and you'd then await on that.

Yeah, I guess I'm nitpicking.

Thanks for the nitpick! I hadn't thought it through all the way. I was mostly thinking about doing async stuff with the inner stuff, but you're definitely right. I'm glad you commented because I've had to rethink it.

True, but you can't chain returns, making this suggested use of a special postfix operation a bad idea imo.

You could chain returns in that case, in principle, but it would just be dead code. The type of a return expression is `!`, the never type.

The problem with that is return doesn't evaluate to anything, so there's no (return foo).bar expressions to benefit from that change. Same problem with break, continue, and goto, for that matter.

I think yield would be a candidate for this syntax because yield can return.