Skip to content

Add allNullaryConstructorTagModifier option #1143

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add allNullaryConstructorTagModifier option #1143

wants to merge 1 commit into from

Conversation

wi11dey
Copy link

@wi11dey wi11dey commented Jul 31, 2025

Often, enums (all nullary contructors) are encoded differently than sum types.

For example, if I have

data State = Launching | Launched | Terminated | MarkedForDeletion

I might want to have these states encoded as LAUNCHING, LAUNCHED, TERMINATED, MARKED_FOR_DELETION, respectively.

However, using the existing constructorTagModifier is not satisfactory for this because I don't necessarily want my sum types, e.g.

data Employee = Manager { subordinates :: [Employee] } | Junior

to be encoded the same way as an enum.

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

@wi11dey wi11dey force-pushed the wdey/allNullaryConstructorTagModifier branch from 5834a26 to 1175bcc Compare July 31, 2025 23:42
@julmb
Copy link

julmb commented Aug 19, 2025

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?

@wi11dey
Copy link
Author

wi11dey commented Aug 26, 2025

@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

@julmb
Copy link

julmb commented Aug 29, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@wi11dey @julmb