Adds "unstable-exhaustive-types" as new feature.

[TheCataliasTNT2k]

This feature deactivates all "#[non_exhaustive]" added into the code. This can be used by developers to ensure, that they match all enum variants or struct fields during pattern matching.

This does not break any existing code.

[jamesbt365]

Your little find and replace has changed the doc comments.

[TheCataliasTNT2k]

Now it should be fixed.

[kangalio]

This can be used by developers to ensure, that they match all enum variants or struct fields during pattern matching.

You can already add a match case for __NonExhaustive to do exactly this, no? That approach also has the advantage of marking the precise spot in your codebase that may break on semver-equivalent version updates

[TheCataliasTNT2k]

You can already add a match case for __NonExhaustive to do exactly this, no?

No.
This variant can not be matched, so you are forced to use a wild card match arm.
That will compile, but I want my code to not compile, if new variants are added.

Using my solution, if I wanted my code to compile nonetheless, I can still add a wild card arm, and everything is fine.

But as long as enums or structs are marked as non_exhaustive or have a variant like you mentioned, I have to have a wild card match arm (which matches any added variants as well), which I do not want.

[kangalio]

This is what I meant

It does work for those __non_exhaustive struct fields and __NonExhaustive enum variants. It does not work for the #[non_exhaustive] attribute. I avoid that attribute in my personal projects for that reason. I wonder why poise uses the attribute in some places, and the manual struct field / enum variant in other places... If the manual way was used everywhere, the problem addressed by this PR addresses would be solved too...

But I just wanted to throw that in. Y'all can decide if banishing #[non_exhaustive] in favor of the configurable manual alternative, or making #[non_exhaustive]'s feature-togglable like currently implemented in the PR, is the better solution

[TheCataliasTNT2k]

I do not know, why serenity and poise use the macro.
I asked some time ago, and got the answer, that it is done to not have breaking changes when not needed. I did not add them.

But I want a way to let my code fail, when new variants / struct fields are added, and this is actually intended by rust.

So I created this solution to get this behaviour.