I'm not sure who is it for, but if it's responsible for Pin and it's related unsoundness issues, that just makes me dislike it even more.
A language with BDFL could have, took a more principled stance and said no async until we prove Pin is safe.
> took a more principled stance
This is very insulting. Bugs are often found in every kind of software. Virtually no languages that exist, let alone popular ones, require proofs before landing new features.
To me it's not a bug. It's a foundational flaw. If Rust was a house, and a bug was a broken window, unsoundness issue would be water seeping into the foundation.
If standard library is unsound, that means pretty much everything derived from/relying on that functionality is unsound.
Adding unsoundness for the sake of pushing a feature out is just bad. It's cutting corners on essential things.
> they also could have said "ship it"
True. But if I know that BDFL is an asshat, then I avoid that project.
Here's why this matters. This response from you is much better! Because:
> If Rust was a house, and a bug was a broken window, unsoundness issue would be water seeping into the foundation.
Yes. Everyone agrees, in principle, that Rust being sound is an important property. Your criticism isn't actually about principles, it (appears to me, anyway) that it is about the specific methods in which we figure out if something is sound or not. You can argue that nothing should be added without formal proof, and that's a fine position to take, but at least it is a specific, actionable criticism that can be discussed directly.
By this standard, virtually all languages have "unprincipled" designers. This isn't even true of only async! We didn't (and still sort of don't) have a formal model of the borrow checker. So you can't really criticize async specifically in this way, you'd have to criticize the entire language.
The way I see unprincipled is two fold: 1) You're breaking your promise 2) In a similar situation behave differently
1) Pin was a problem from the start. Allowing it into std/core was a mistake. The fact they allowed an almost blatantly unsound feature is unprincipled.
I'm not 100% sure of the timeline, but near or before the release there were examples floating of a possible Pin unsoundness. And defense was, it's an obscure thing, no one would really use that in practice. The moment designer says, no one would use that in practice, is the moment they lost.
2) Yeah, I get async was a feature everyone wanted. By same measure, why not add self-referential struct. People want it. It's probably unsound but you can't tell. Maybe there exist a model that allows self-referntial structs.
Similar situation, different behavior
People do want it, and in fact, it is part of async, and directly related to the soundness issues you’re complaint about. The reason such things aren’t in stable is that, while people do want it, people wanted async more, and did the work. The work has to happen, features don’t just magically come into existence.
It doesn't appear to be unresolvable.
But what if the issue was unresolvable? Rust would either have to rollback a feature or basically say, we're sound, except for that part.