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
Add Rule::Other to cover newly defined flags. #682 #685
Conversation
Thanks for helping out! This technically still breaks compatibility, since it adds a variant on an enum that is not marked as non-exhaustive. That's fine, though, since the main branch already broke compatibility. Given that this is the case, I think it would make sense to also add variants for any newly defined flags that we know about at this point. |
Instead of causing compatibility issues every time a new flag is added, Rule::Other is used as a transitional solution to ease compatibility. Rule may enumerate explicitly a list of commonly used flags. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. @jaymell any thoughts?
I can be persuaded here, but I'm not thrilled with the change. The core issue, of course, is the existing API has not left us with great options. But I wonder if, given that we're going to make a backward-incompatible change here, if we should consider marking the enum as non-exhaustive and adding in the new variants as appropriate? |
The non-exhaustion structure has too many limitations and imposes too much mental burden. Rule::Other is just for exhaustion and ergonomics. I suggest putting this break change into the next non-compatibility release. |
Ok, merging this. Thanks for the contribution. |
Fix bug of unhandled newly defined flags when call
acl_getuser
.