I am writing a first pass at reference material for the book. Along the way, I noticed that the async-await RFC says that the
? operator's behavior has not yet been determined. And yet it seems to work fine in an async block (playground). Should we move that to a separate feature gate?
responded on the issue
this was initially a point of discussion
but we discussed it in further lang team meetings and decided that we were all okay with
? all working as they did in closures, which is really the only possible option
? would essentially make
await dead-on-arrival given that almost all futures return
i don't know if that decision was ever recorded anywhere, given that discussion over this has spread across so many issues and meetings over time.
but we discussed it in further lang team meetings and decided that we were all okay with return/break/continue/? all working as they did in closures, which is really the only possible option
I don't recall this, but I also don't think there's anything strange going on here so I'm fine with shipping it.
That said, looking over the "existing tests" list I see no mention of
I mean, I don't think
? is "anything special" here-- its behavior falls out as an obvious consequence of async blocks being a kind of closure.
but it seems fine to me to add tests for that, break, continue, return, etc.
Frankly, that comment should not have been allowed to be added to the RFC
There has never been any serious doubt about the behavior of ?
I mean, I don't think ? is "anything special" here-- its behavior falls out as an obvious consequence of async blocks being a kind of closure.
That presumes a sane compiler and a sane implementation
I assume the implementation is wrong when thinking of tests
and it's also important in terms of avoiding regressions
seems like tests for all control flow operatos would be fine
(I tested quickly at playground... seems nothing strange is going on, but the one bit that stood out is that https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=42f1c7732a5623674481654189f517ee gives subpar diagnostics that leaks the fact that it behaves like a function)
(That doesn't seem blocking, but it would be good to improve diagnostics here)
(Filed as: https://github.com/rust-lang/rust/issues/62570)
I agree we should just stabilize existing behavior of
I also agree we should write some tests :)
@Taylor Cramer do we permit
return to "return" from the block?
it...seems we do.
Into where does it return?
Into the result of the future, as with a closure.
And yes this connects to your other topic :)
otoh this makes async blocks into implicit try blocks, in a sense- they're intentionally not like closures in a lot of ways so it seems strange and unnecessary to allow
? just because the implementation is straightforward
/me not inclined to revist a basic question like this at this stage
(although I agree that
return in particular feels surprising to me)
i too find it very awkward that
return has closure semantic without the closure syntax (the