|
|
|
|
|
by sitkack
1003 days ago
|
|
I think the answer is that when you break compatibility for an old compiler, you rev the major version. The folks on the old compiler then get to use the old library forever. Yeah, they can pin (and should) but it makes it a little cleaner. |
|
For languages with more frequent releases, that just isn't feasible. The let-else construct [0] was stabilized in 1.65 (Nov 2022), default values for const generics were stabilized in 1.59 (Feb 2022) [1], and the const evaluation timeout [2] was removed in 1.72 (Aug 2023). These are all reasonable changes, released on a reasonable timescale. However, when writing a `struct Position<const Dim: usize = 3>`, I don't check whether my library already uses language features that post-date 1.59, and I don't consider it a backwards-compatibility breakage to do so.
Incrementing the major version for a change that is source-compatible on most compiler versions (e.g. the first use of let-else in a project) just isn't justified.
[0] https://doc.rust-lang.org/rust-by-example/flow_control/let_e...
[1] https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html#const...
[2] https://blog.rust-lang.org/2023/08/24/Rust-1.72.0.html#const...