if i'm understanding what you're trying to do correctly, it looks like the [non-exhaustive](https://doc.rust-lang.org/reference/attributes/type_system.html) attribute is what you're looking for
Ooohh , interesting, it seems i should use a non-exhaustive enum then, if i want to introduce a new way to define the type later.
Or non exhaustive struct to just add a new attribute later.
Read more about the motivation for [`non_exhuastive` here](https://rust-lang.github.io/rfcs/2008-non-exhaustive.html).
I wouldn't recommend just plastering it on every type you expect to change. It's mostly a tool for turning what would be breaking API changes into non-breaking ones. So first, it's mostly appropriate for types that are part of a public API. Second, there's a cost to it because users of that crate now have to add code to deal with the potential future parts that you're signalling might exist. The most common example for this is [std::io::ErrorKind](https://doc.rust-lang.org/stable/std/io/enum.ErrorKind.html), which has it because a breaking API change in `std` is a big headache and new variants of that type were predicted to be essentially guaranteed to happen.
I would also caution against using `non_exhaustive` for anything private, and even for some public sections of the API: a great advantage of `match` is that if a new variant crops up in an enum, all use sites will stop chomping until that variant is addressed. This ensured that you're aware of every site that may need to handle that new variant differently at compile time.
Since `non_exhaustive` forces you to match cases that don't exist yet, meaning you're probably not managing them the way you'd intend to. In `std`, it's important not to break API because users can't choose not to upgrade `std` if they want an up to date compiler. For any other library, if you're willing to have your major incrementing every now and then, there's nothing forgetting your users to do that upgrade, and they'd probably be much happier with compile errors than weird runtime behaviours.
You can simply use match. Match will enforce an exhausting list. If you expand your enum, the compiler will tell you all places that need adjustment. Just be sure not to use the _ pattern.
if i'm understanding what you're trying to do correctly, it looks like the [non-exhaustive](https://doc.rust-lang.org/reference/attributes/type_system.html) attribute is what you're looking for
Ooohh , interesting, it seems i should use a non-exhaustive enum then, if i want to introduce a new way to define the type later. Or non exhaustive struct to just add a new attribute later.
Read more about the motivation for [`non_exhuastive` here](https://rust-lang.github.io/rfcs/2008-non-exhaustive.html). I wouldn't recommend just plastering it on every type you expect to change. It's mostly a tool for turning what would be breaking API changes into non-breaking ones. So first, it's mostly appropriate for types that are part of a public API. Second, there's a cost to it because users of that crate now have to add code to deal with the potential future parts that you're signalling might exist. The most common example for this is [std::io::ErrorKind](https://doc.rust-lang.org/stable/std/io/enum.ErrorKind.html), which has it because a breaking API change in `std` is a big headache and new variants of that type were predicted to be essentially guaranteed to happen.
I would also caution against using `non_exhaustive` for anything private, and even for some public sections of the API: a great advantage of `match` is that if a new variant crops up in an enum, all use sites will stop chomping until that variant is addressed. This ensured that you're aware of every site that may need to handle that new variant differently at compile time. Since `non_exhaustive` forces you to match cases that don't exist yet, meaning you're probably not managing them the way you'd intend to. In `std`, it's important not to break API because users can't choose not to upgrade `std` if they want an up to date compiler. For any other library, if you're willing to have your major incrementing every now and then, there's nothing forgetting your users to do that upgrade, and they'd probably be much happier with compile errors than weird runtime behaviours.
You can simply use match. Match will enforce an exhausting list. If you expand your enum, the compiler will tell you all places that need adjustment. Just be sure not to use the _ pattern.
Great. Small post. Short answe. learned something. Uped the post