Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replacing an enum with a typedef is breaking and a hazard, but not semver-major #413

Open
obi1kenobi opened this issue Mar 5, 2023 · 3 comments

Comments

@obi1kenobi
Copy link
Owner

Replacing an enum with a typedef is a breaking change, due to the inability to glob-import via the typedef.

But not all breaking changes are major — so is this one major? Is it minor? Should it instead just be a warn level lint pointing out the hazard?

Playground link

fn main() {
    // Works
    // enum Foo {A, B}

    enum SecretFoo {
        A,
        B,
    }
    type Foo = SecretFoo;
    
    // Works fine
    let x = Foo::A;

    // Doesn't work
    use Foo::*;
    let y = A;
}

Example courtesy of @aDotInTheVoid.

@obi1kenobi
Copy link
Owner Author

It's not just glob imports that are problematic. Replacing the glob with a direct import of the variant (use Foo::A) doesn't work either.

@obi1kenobi
Copy link
Owner Author

I believe this is just a hazard, not breaking. I've laid out my reasoning here: https://predr.ag/blog/re-exporting-enum-with-type-alias-breaking-change-not-major/

@obi1kenobi
Copy link
Owner Author

This issue just happened in the time crate in v0.3.35: time-rs/time#675

@obi1kenobi obi1kenobi changed the title Is replacing an enum with a typedef semver-major or just a hazard? Replacing an enum with a typedef is breaking and a hazard, but not semver-major Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant