So I wonder how std will incorporate a runtime implementation that happens to be compatible with all ongoing runtime flavours, so that those breaking changes don't happen.
So I wonder how std will incorporate a runtime implementation that happens to be compatible with all ongoing runtime flavours, so that those breaking changes don't happen.
When I think of breaking changes, I think removing sun.misc.Unsafe. Which, yes yes, was never supposed to be used, but still was. Evolution of best practices and introduction of alternative implementations doesn't break anything.
It's still not clear what this has to do with being a "breaking change" though. Like, if I were to use the serde-json crate in my project, the fact that the json crate exists, but has a slightly different API, does not mean that somehow this is a "breaking change." Moving between two or three different libraries is not the same thing.
Right now Rust is looking to have as many async/await variants as there are C++ string libraries, with the same amount of interoperability headaches.
You're the one claiming it is, it's up to you to demonstrate how.
Even C++ has learnt the pain of not having basic language libraries as standard library type in what concerns interoperability across libraries.
Async runtimes not being part of std was a surprise to me.
Interoperability is good! We have more work to do to make async more interoperable, absolutely. That doesn't mean that "async/await is a breaking change."