As I understand it this is one purpose of Rust's "Editions" behaviour. They can deprecate something, suggesting what you ought to do instead, and then in a subsequent edition they can actually outlaw it. Your old code still compiles, since that was for the earlier edition, and editions compose in both directions perfectly well so that the ecosystem isn't fragmented, but new projects will be written for a newer edition where the deprecated code now does not compile, and so the deprecated practice actually dies out in the minds of programmers, rather than limping on forever because of doubts about backward compatibility.
Rust is a young language, perhaps in twenty years we'll know that editions weren't powerful enough, but it seems like a good start. This year will see a new edition (Rust 2021) with a handful of such changes, such as requiring you always write 1..=9 not the historical alternative 1...9 when you mean that the range should be exactly 1,2,3,4,5,6,7,8,9.
Comments
As I understand it this is one purpose of Rust's "Editions" behaviour. They can deprecate something, suggesting what you ought to do instead, and then in a subsequent edition they can actually outlaw it. Your old code still compiles, since that was for the earlier edition, and editions compose in both directions perfectly well so that the ecosystem isn't fragmented, but new projects will be written for a newer edition where the deprecated code now does not compile, and so the deprecated practice actually dies out in the minds of programmers, rather than limping on forever because of doubts about backward compatibility.
Rust is a young language, perhaps in twenty years we'll know that editions weren't powerful enough, but it seems like a good start. This year will see a new edition (Rust 2021) with a handful of such changes, such as requiring you always write 1..=9 not the historical alternative 1...9 when you mean that the range should be exactly 1,2,3,4,5,6,7,8,9.