Yeah, I think I clarified what I meant in my previous reply. Consider the optics of this from a casual Rust observer (e.g. your manager at work to whom you’re pitching Rust). 1.26 comes out - 2 point releases, unsoundness in a lang feature. 1.27 comes out, another instance of unsoundness. The fact it’s lingering from something introduced in 1.26 is a technical detail. Then you consider that the feature in question is intended to improve ergonomics and beginner-friendliness, yet beginners are the ones most likely to inadvertently write something that will trip over this. Then you consider that this feature’s utility was fairly highly contested in the first place.
That’s essentially the thrust of my point. I’m hoping this will serve as a concrete example to strengthen that thinking. That’s not to say the core team (and the rest of the community, for that matter) doesn’t already think hard about these things. But, we have a couple of real examples to look at now and learn some lessons.
By the way, to be super clear, I’m not suggesting to not touch code at all. But as we all know, from our own experience, touching code always risks bugs. So we mentally weigh the cost/benefit of this. The scrutiny is also elevated if you’re touching something that you already know is brittle, or at the core of your system, where the cost of a bug will be more severe. So proposed changes go through this triaging exercise, and they aren’t all measured by the same stick.
Certainly, and I agree with all of that, including Rust doing a great job on this front. But, I’ll tell you why I personally find this case particularly troublesome.
We’re all told (and rely on) to “trust the compiler” - it will fail to compile unsound code. Bugs happen, yes. But, here’s where things get “interesting” - in canonical Rust code, it’s very hard to mentally parse all the involved types and their interactions/coercions/etc due to heavy type inference usage. So you’re doing a code review. You’ll almost certainly assume that if it compiles, and there’s no unsafe code, then it’s sound. This is where Rust is somewhat unique; if you’re looking at, say, C++ code, you’re likely not going to sleep on it because you know the compiler ain’t doing much to detect soundness problems. C++ also doesn’t have the type inference engine that Rust does, nor do people use unascribed types as much.
So I feel that rustc has the extra burden of being airtight. Yes, bugs will happen. It just sucks to waste the “bug budget” on things like match ergonomics.
