I thought it was bizarre that
std::Futurewas stabilised before the design/implementation ofasync-awaitwas completed. It seemed like a bad idea for exactly this kind of reason.
I agree it was not ideal from a process POV where the main issue was Pin<T> which in hindsight should not have been approved by the library team and should have also needed language team approval instead. Even so, that probably would not have changed anything.
Although, for what it's worth, I did ask some vague questions about exactly this at the time, #55766 (comment) which was replied to in #55766 (comment) which does not seem true today. Unfortunately, Ralf did not have a time machine.
In the end, it was just happenstance that we noticed this now which is mainly because the UCG got to this point. We could have easily stabilized all of pin, futures, async_await and found this out 2 months later. Mistakes where made, and we have to live with them.
I guess the Rust teams hand was a bit forced by Tokio's refusal to implement against unstable futures though.
Yes, that didn't help. In the future I think that we need to be clearer that stakeholders pushing for a feature need to be part of testing it out on nightly.
Soundness bugs are an exception, right?
They are, but we still have to be careful even in the even of a soundness bug to deal with the fallout in a graceful way.
Unintentionally altering the languages memory model would seem to be in a similar category to me. It's unfortunate, but unless a workaround can found, I think breaking changes to
std::Futureshould strongly be considered.
@RalfJung's comments in rust-lang/unsafe-code-guidelines#148 (comment) suggests that a workaround can be found to recover noalias for code which does not care about Pin.
The desire for
async-awaitis strong. But there are also lot's of people who will never use this feature.
Certainly; For example, I don't expect I will personally use this feature that much, at least not now.
For this feature to unexpectedly have a significant impact on non-async code generation is not something the community is likely to take well. Even as someone who is hotly anticipating async-await, I would be pretty concerned with that.
See above re. @RalfJung's notes. I believe we should be able to recover noalias at the cost of complicating our operational semantics. This cost will primarily be borne by 1) unsafe code authors who will have to account for this in their mental model, 2) Rust compiler developers (including prospective alternative compilers), and 3) PhDs and language specifiers like @RalfJung. On the other hand, having something like &pin T would have added type system complexity instead of costs in the operational semantics so there's a trade-off here and it's not so clear that complexity in the type system is better or worse than in the abstract machine.
Regardless of the decision taken, I think this merits serious consideration rather just "It's stable: there's nothing we can do now".
For what it's worth I have debated this internally and given it a non-trivial amount of thought.
It's better to propagate breaking changes across a very small community now rather than suffer when it will really be too late to fix.
Sure, it's always true that a breaking change is easier to propagate when fewer rely on them. However, I believe you are underestimating the disruption this would cause both to code and to trust in our leadership.