You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've added an optional field allNullaryConstructorTagModifier (it's Maybe so that there's no behavior change to any existing usages of Aeson, in case someone is depending on constructorTagModifier also applying to all-nullary datatypes). When it's Nothing, everything is the same as today. When it's non-Nothing it's used instead of constructorTagModifier for all-nullary datatypes, for the purposes of handling enums differently than sum types.
Please let me know if you'd like any changes to the api
Since your State and Employee types are different types, why not just use a different Options value (with a different constructorTagModifier) for each of the types? Is it important to you that the same Options value can act differently on different types?
@julmb That's fair, though yes I would like to reuse the same Options value as I'm using DerivingVia to derive FromJSON for a bunch of different types. I think the same logic of just using a different Options value could also apply to the existing allNullaryToStringTag, where you could just set your sum encoding to UntaggedValue for data types you know have all nullary constructors. If you feel strongly about not adding this though, I can live without it and close
If you feel strongly about not adding this though, I can live without it and close
Oh, this might be a misunderstanding, I am not a maintainer of aeson and I have no say in whether this PR gets accepted. I was just asking out of my own curiosity.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Often, enums (all nullary contructors) are encoded differently than sum types.
For example, if I have
I might want to have these states encoded as
LAUNCHING,LAUNCHED,TERMINATED,MARKED_FOR_DELETION, respectively.However, using the existing
constructorTagModifieris not satisfactory for this because I don't necessarily want my sum types, e.g.to be encoded the same way as an enum.
I've added an optional field
allNullaryConstructorTagModifier(it'sMaybeso that there's no behavior change to any existing usages of Aeson, in case someone is depending onconstructorTagModifieralso applying to all-nullary datatypes). When it'sNothing, everything is the same as today. When it's non-Nothingit's used instead ofconstructorTagModifierfor all-nullary datatypes, for the purposes of handling enums differently than sum types.Please let me know if you'd like any changes to the api