-
Notifications
You must be signed in to change notification settings - Fork 2
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
Automatic Enum representation #7
Conversation
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.
LGTM.
Looks like the Travis build is failing due to |
/cc @gracjan @mariuszrak |
I don't have an opionin really. You can drop support of GHC < 7.10.3 if it goes about me. |
LGTM |
Pushed some patches for older GHCs compat, dropped support for GHC 7.6. 7.8+/7.10 will still be supported for a while. |
Merged, thanks! |
Thank you! Sorry for the hassle, I'll be more backwards-compatible next time. I guess we can go forward with the new release :) |
Personally, I don't think it is unfair to only support GHC >= 8 for new releases. |
Good rule of thumb is "support all GHC versions released in the last 3 years", which includes 7.10.3 at the moment. |
@f-f Released version 0.15.0.0 on Hackage. |
We thought that writing enum representations by hand was a lot of characters (our domain has quite a lot of sum types in some places), so we automated it.
Example from our codebase:
Before defining
enumUnjsonDef
we had to write this:After:
Downsides of this: pulls in the
TypeApplication
extension, which was introduced in GHC 8.0. But if this is a problem I guess we could just add some otherifs
on the GHC version to pull this in when possible.