Post: Stabilizing async fn in traits in 2023

[tmandry]

This post lays out our plan for how to stabilize async fn in traits in 2023. Co-authored with @nikomatsakis.

cc @rust-lang/wg-async

Targeting Wednesday May 3 for publishing.

[yoshuawuyts]

I'd love to make time to review this, but won't be able to during the weekend. Can the target publication date be pushed back to Tuesday instead of Monday so we can have at least one workday to read this over?

[tmandry]

Pushed to Tuesday.

[calebcartwright]

exciting stuff! one likely typo and potential missing link noted below

[tmandry]

Feedback should be addressed now.

[yoshuawuyts]

In my opinion this post does not yet accurately represent the collective decisions made by the Async WG. Unless these decisions were walked back in a later meeting I was not present for ¹, I would like to see them represented in this post. Specifically, I believe the following changes should be made:

1. The phrase: "We explored a number of solutions and concluded that associated return types are the most practical." could be read to suggest we are happy with the ergonomics of associated return types, while in the meeting on case studies it was clearly established that using it felt "overly verbose" and unpleasant. The "MVP part 2" section should make it clear that we're not yet satisfied with the ergonomics.
2. During that same meeting we agreed that we would ship a proc macro to address the ergonomics concerns ². We should not just mention in passing we may ship a macro, but highlight this as a key part of our strategy. The phrase "we hope to provide a proc macro" does not accurately capture this, and should be reworked.
3. We dedicate significant space to showing associated return type notation, which we established would be unsatisfactory as the primary interface to declare send bounds. While I don't think this is the right post to speculate about trait transformer syntax, I do believe we should show the experience users will be able to expect using a proc macro ³.

Footnotes

1. For on-readers: The Async WG has moved to a meeting schedule which alternates between EU-friendly and Asia/Oceania-friendly times every week. This means it's a legitimate possibility that this decision was walked back in a meeting in one of the EU off-weeks. I am however unaware of such a decision, so I'm writing this under the assumption that what we last agreed to still holds. ↩

2. From the meeting notes: "[…] it sounds like the min version of this feedback is that we need to have the macro or it’s going to be super annoying." We continued discussing this in the meeting and agreed we would work on a proc macro to ship from day one when AFIT stabilized. ↩

3. My understanding is that such a macro has been written already, but currently exists in a gist (which I have not seen). Even if we didn't have this, it's not hard to imagine what an attribute macro in the style of async-trait would look like for this purpose. ↩

[tmandry]

@yoshuawuyts I added a preview of the proc macro syntax along with some wording alluding to this in the MVP Part 2 section. I think the post heading is quite clear in saying what I think the post should say:

Send bounds are verbose, especially for traits with lots of methods

I don't personally see a need to put this more front and center, because I don't think most readers will be directly affected or think about this, and I still think we need to gain more experience with the feature to see how often this becomes annoying in practice. (I hope this doesn't come across as dismissive of your or @eholk's experience – I think it's valid and that's why this section exists in the post in the first place.)

The phrase: "We explored a number of solutions and concluded that associated return types are the most practical." could be read to suggest we are happy with the ergonomics of associated return types, while in the meeting on case studies it was clearly established that using it felt "overly verbose" and unpleasant. The "MVP part 2" section should make it clear that we're not yet satisfied with the ergonomics.

Implying that isn't really my intent, but I think the statement still rings true. I added some wording to the post that explains why: People have a need for the fine-grained control provided by ART, so we should stabilize that more general mechanism first. I feel good about the sentence you quoted, but happy to take suggestions for rewording.

[nikomatsakis]

Minor nits.

[yoshuawuyts]

I had already logged off for the day, but I also don't want to further delay this post. @tmandry: from skimming the updated text it seems like it now more closely represents what we had agreed on. I haven't yet read Niko's proposed change, but from the context I trust it enough that between you two you can agree on the right phrasing to use.

Removing my blocking concern; thanks so much to both of you!

[eholk]

Looks good to me. I made a couple suggestions, but I think the most important thing is to get this post out there so feel free to ignore my comments.

[eholk]

Send bounds are verbose, especially for traits with lots of methods

I don't personally see a need to put this more front and center, because I don't think most readers will be directly affected or think about this, and I still think we need to gain more experience with the feature to see how often this becomes annoying in practice. (I hope this doesn't come across as dismissive of your or @eholk's experience – I think it's valid and that's why this section exists in the post in the first place.)

I'm okay with how this is written. It highlights that we are aware of some ergonomic issues, but I think it's true we need more experience to find out big of an issue this is in practice. Publishing this blog post also serves as a call for people to try it out and see if it works for them.

The only potential open question we have is whether we are 100% convinced people will need or want the extra flexiblity afforded by ART. It seems likely to me that we will, but I also don't feel like we have a lot of data yet that says this. That said, I think it's fair to say that the sense of the group is that we will need this flexibility so we can stabilize it now and iterate on a less verbose solution.

[nikomatsakis]

FYI: I plan to post today around 10am US Eastern