DType enum changes in 0.9.2 patch release violated semver - please add #[non_exhaustive]

[antimora]

Summary

New variants were added to the DType enum (I16, I32, F8E4M3, F6E2M3, F6E3M2, F4, F8E8M0) in the 0.9.2 patch release. This is a semver-breaking change that was released without a major version bump.

In Rust, adding variants to a public enum is a breaking change because it breaks exhaustive match statements in downstream code. According to SemVer, breaking changes require a major version increment. Patch releases (0.9.1 → 0.9.2) should only contain backwards-compatible bug fixes.

Example breakage

burn-import v0.20.1 fails to compile with candle-core v0.9.2:

error[E0004]: non-exhaustive patterns: `candle_core::DType::I16`, `candle_core::DType::I32`, 
`candle_core::DType::F8E4M3` and 4 more not covered
  --> burn-import-0.20.1/src/common/candle.rs:62:15

Suggested fix

To allow adding variants in future minor/patch releases without breaking downstream crates, add #[non_exhaustive] to the DType enum:

#[non_exhaustive]
pub enum DType {
    // ...
}

This forces downstream crates to include a wildcard arm (_ => ...), making future variant additions non-breaking.

References

• Rust API Guidelines: C-STRUCT-PRIVATE
• Cargo SemVer: Adding enum variants

[kristof-mattei]

https://semver.org/#spec-item-4

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

[jcrist1]

https://semver.org/#spec-item-4

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

I think this is a bit disingeuous. The community should still strive for semver consistency. Would it be possible to yank 0.9.2 and release as 0.10?

[danielclough]

Bumping the major version seems like the right choice according to The Cargo Book.

Initial development releases starting with “0.y.z” can treat changes in “y” as a major release, and “z” as a minor release. “0.0.z” releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible.
...
Major: adding new enum variants (without non_exhaustive)
It is a breaking change to add a new enum variant if the enum does not use the #[non_exhaustive] attribute.

#[non_exhaustive] enforces wildcard patterns based on crate boundaries, not repository or workspace boundaries, so it's not a great option IMO.