Drop order of async fn arguments doesn't exactly match the equivalent regular fn.

[davidtwco]

While #59823 resolved async fn arguments being dropped before the function was polled, the resulting drop order still does not exactly match the equivalent fn.

This is visible in this playground example which compares the drop order of four functions with and without fn and async fn. This is a behavior of closures which can be seen in this playground example which approximates the desugaring of async fns.

[Centril]

So in my view, this should be considered blocking for the same reason as the other drop issue. However, if it comes to it and we cannot fix it in time for stabilizing, we can feature gate this part and move on.

[nikomatsakis]

The only argument I can come up with in favor of this drop order is basically:

• the existing drop order of fn is not what we would have wanted (I believe this, but I also doubt its worth trying to change it)
• having a simple desugaring for async fn is important

You might make a case that, because people sometimes have to manually desugar into a fn that returns an async block for various reasons, having a simple transformation is important.

But I think this whole case sounds a bit weak to me -- in contrast, matching fn and async fn as closely as possible feels like what would people would expect

Of course I also think that the drop order between fn parameters, particularly when intermingled with complex patterns, is highly unlikely to matter, but who's to say what people ultimately rely on.

Still, this implies that most of the time, people can desugar any which way to use an async move block and it will be fine.

[nikomatsakis]

I'm going to mark this as blocking for now.