-
Notifications
You must be signed in to change notification settings - Fork 162
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
Reconsider Public Enum Usage #380
Comments
Removing cases will break source compatibility no matter what we do, but from what I can see the adding problem only exists when tied into exhaustivity checking – when a user has to cover all cases. Are there some examples that are likely to hit users? In this case, I'm not sure when users would switch over meta tag names and implement them all, and if someone they did do that then they'd probably want to be notified when another case was added. |
In the end, it's a decision that needs to be consciously made, and if we decide it's something we're ok with then that's also completely fine 👌 At any rate, feel free to close this if it is not relevant for Ignite 👍 |
Very happy to revisit this down the line if we find any of our existing |
I was in the process of reviewing #373 and decided to open a discussion regarding Ignite's use of public-facing enums.
Problem
Public enums in our API risk introducing source-breaking changes for users.
If developers switch over these enums, adding/removing a case will break their code.
This forces us to treat every enum modification as a breaking change, slowing iteration.
Proposed Solution
Replace public-facing enums with struct-based static constants. For example:
Benefits
Considerations
This approach is used by other Swift frameworks to promote API stability (eg. Vapor)
Next Steps
Questions
The text was updated successfully, but these errors were encountered: