Skip to content

Conversation

wi11dey
Copy link

@wi11dey wi11dey commented Jul 31, 2025

Hello,

Thanks for making aeson.

I've added a flag tagAsContentsFieldName which will allow encoding sum types as

{
  "tag": "constructorName"
  "constructorName": { ... contents ... }
}

This style is used in type encoding standards such as https://palantir.github.io/conjure/#/docs/spec/wire?id=_54-union-json-format.

Initially I was thinking to make contentsFieldName be a String -> String and provide it the constructor name, which would be flexible enough to allow the default behavior of const "contents" and also be able to dynamically use the constructor name (and even modify it), but this would break backcompat and also not be serializable to the TH implementation.

Please let me know if you'd like any changes to the proposed API

@julmb
Copy link

julmb commented Aug 22, 2025

I could use something like this in one of my projects. However, the constructor

TaggedObject { tagFieldName :: String, contentsFieldName :: String, tagAsContentsFieldName :: Bool }

admits the semantically questionable value TaggedObject "type" "item" True. If tagAsContentsFieldName is True, then the value in contentsFieldName is meaningless. I feel like it would be better to have

data ContentsFieldName = FromTag | Fixed String
... TaggedObject { tagFieldName :: String, contentsFieldName :: ContentsFieldName } ...

Alternatively, instead of ContentsFieldName, we could also use the isomorphic Maybe String, with a documentation note that a contentsFieldName value of Nothing means that the contents field gets the tag value as its name.

We could be even more extreme and not change any of the types in TaggedObject and simply treat contentsFieldName being the empty string as an indicator for using the tag value as content field name.

@wi11dey
Copy link
Author

wi11dey commented Aug 26, 2025

We could be even more extreme and not change any of the types in TaggedObject and simply treat contentsFieldName being the empty string as an indicator for using the tag value as content field name.

I like this. I've updated to the PR to this behavior. Let me know if it looks good to you

@wi11dey wi11dey force-pushed the wdey/tagAsContentsFieldName branch 2 times, most recently from 236d9b8 to 80639fa Compare August 26, 2025 19:05
@wi11dey wi11dey force-pushed the wdey/tagAsContentsFieldName branch from 80639fa to fd0fea8 Compare August 26, 2025 19:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants