Follow up to “Changing the rules of Rust”

# · ✸ 78 · 💬 15 · 4 days ago · without.boats · killcoder
In my previous post, I described the idea of using an edition mechanism to introduce a new auto trait. If all of foo, bar, and baz compiled, it must be quux which doesn't compile, regardless of what edition it's compiled under. The error cannot be in foo, because because surely traits with generic methods are not an error and will not become an error in 2024. The error cannot be in baz, because nothing in baz is invalid at all: you instantiated a generic interface with a type that meets the bounds of that interface. Upgrading your crate to a new edition has historically not been considered a breaking change, except insofar as it raises your MSRV. This is very important for achieving a seamless upgrade across editions, as everyone will not upgrade at once. If you say the error is in bar, for example, the implication is that upgrading foo from 2021 to 2024 is a breaking change, because you can implement both foo and bar exactly as written under edition 2021 today. What are the rules you are enforcing to make quux error? And how do you explain them to users so that they have half a clue what's going on when they run into this issue in a practical scenario? Good luck!
Follow up to “Changing the rules of Rust”



Send Feedback | WebAssembly Version (beta)