4 ms·
Though, I want to make clear that it is permissible for some theoretical code to stop compiling when going from 1.4 to 1.5, for example. Check out https://gith
by Tyr42 11y ago
Though, I want to make clear that it is permissible for some theoretical code to stop compiling when going from 1.4 to 1.5, for example. Check out https://github.com/nikomatsakis/rfcs/blob/projection-and-lifetimes/text/0000-projections-lifetimes-and-wf.md https://github.com/nikomatsakis/rfcs/blob/projection-and-lif..., for an example of this.
This is because the compiler wasn't checking some cases strictly enough, and you could "hide" constraints from the compiler, causing them to fail to be enforced.
They checked against crates.io when raising this RFC, and found that there were 35 crates (packages) that would be able to keep compiling if this turned into a future-compat warning, to become an error in the release afterwards.
The example
trait Test {
fn test(&self) -> Option<Self>;
// ~~~~~~~~~~~~
// Incorrectly permitted before.
}
Should be
trait Test: Sized {
fn test(&self) -> Option<Self>;
}
Because `Option<T>` requires that `T` be `Sized`.
Poking around on 1.3, I think that it would be an error to instantiate this trait with a [i8] or something that was not sized anyways, so you're not losing much by needing to declare the trait properly.
- kibwen 11y agoTo elaborate, Rust has a category of bugs called "soundness bugs" which are allowed to justify breaking backwards compatibility, though the team still endeavors to make breakage as minimal and painless as possible. The Rust developers have written a tool called Crater to gauge the impact of any potential change to the compiler, which is actually really neat: it compiles nightly versions of the compiler against every package on crates.io (the central third-party package repository) and generates a report of any packages that fail to compile due to changes to the compiler. To answer the question of why they don't bump the major version when soundness fixes break backcompat, it's because soundness bugs generally have implications for memory safety/undefined behavior, and it's assumed that people using Rust would prefer unsound code to break rather than to continue being potentially unsafe. Also, thanks to Crater, the Rust developers generally take it upon themselves to file patches with third-party crates to update them such that the package developers themselves are (ideally) neither blindsided nor inconvenienced.
- ColinDabritz 11y agoNeat! That's very good handling of "as intended". Being explicit about it, having a warning phase, then moving to "more correct" to match the intent, and missed edge cases.