As I understand it from @withoutboat’s blog, prefix await isn’t out of the running officially, it’s just expected to lose when the final syntax decision is put to a vote.
Given how contentious the proposals are, why would we be certain that the macro would be deprecated “soon”, much less “within 1-2 release cycles”?
3 Likes
Assuming I have a value val: Pin<P> where P::Target: Future but not P::Target: Unpin. Am I supposed to be able to await that pinned future?
Looking at the structure of the current macro, the only difference is that the pinning has already been performed. Still, since Pin<P> is not itself impl Future, it will not work. Is this an intentional restriction?
If not, this has some bearing on the semantical discussion. For a field based syntax, or other syntax that magically works solely on impl Future, this will either never be possible (e.g. val.await shouldn’t work) or be another magic special case. But, for a trait based solution (trait Await, see above) such an extension could be introduced naturally later on for extra awaitable types within the standard library. With the restriction that they must not be impl Future so that such an impl is unique. Which would, in an interesting and useful quirk, also automatically disallow implementing that trait for the user.
(I had previously unintentionally posted this in the wrong thread, sorry)
impl Future for Pin<impl Deref<Target = impl Future> + DerefMut + Unpin> already exists (link not guaranteed to precisely work if the number/order of impls on that page changes).
1 Like
Because discussion is most likely going to stall over the course of 6 weeks and that will lead the lang team to make a decision to prevent blocking asyc/await any longer. Also, thd entire point of asyc/await is more ergonomics and better diagnostics, and using the await macro wouldn’t give good diagnostics, so it doesn’t work.
I don’t understand your first point. Stabilizing the macro would mean that async/await wouldn’t be blocked any more.
1 Like
Ah, yes that is true! 
1 Like
I think the “answer” is “don’t pre pin it”. Since Pin<P<impl Future + !Unpin>> roughly would mean “started future”, I personally fail to see when awaitting it elsewhere would be correct. (In fact, it’s incorrect if it’s being awaited elsewhere, as one of the two await points would thus poll it after finishing.)
Hi all,
I’ve just read the summary and I would agree about the convenience of the prefix solution. I am far to be an expert in programming language design but I’d like to contribute with a humble suggestion: given that the dot keyword syntax conflicts with field access, how about replacing the dot by a question mark?
The syntax would be something like the following:
foo()?await.bar()
I think this would be congruent with the ? keyword already added to the language: the new keyword would work in a similar way and it can be understood as an extension or special case of the former one as well.
The new keyword ?await would manage any result returned by the precedent expression the same time it awaits its future execution .
I think this would be more convenient than using .await.
This is not a good idea because it ties together awaiting and error handling. What if we later add a way to unwrap generically. Example syntax below (I know this syntax is ambigious).
let x = res!; // unwrap the result
Would we also need to add !await so taht we can unwrap the result and then await after? This doesn’t solve the problem, and is no better than prefix await? as seen in the previous thread.
Now if you mean that ? and await would be separate things. Then this is the same proposal as future await, which the lang team discussed in this post.
I meant I would agree about the convenience of the suffix solution
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.