Customize sum type JSON encoding and decoding

[nicolashery]

Is there a way to customize the JSON encoding/decoding of sum types?

Here is a simplified example of what I'm working with:

module main

import json

struct Item {
	id   string
	name string
}

struct AddItem {
	item Item
}

struct UpdateItem {
	item Item
}

struct DeleteAllItems {}

type Action = AddItem | UpdateItem | DeleteAllItems

fn example_actions() []Action {
	return [
		AddItem{
			item: Item{
				id:   '1'
				name: 'item1'
			}
		},
		UpdateItem{
			item: Item{
				id:   '1'
				name: 'item1-updated'
			}
		},
		DeleteAllItems{},
	]
}

fn main() {
	println(json.encode_pretty(example_actions()))
}

This outputs:

[
  {
    "_type": "AddItem",
    "item": {
      "id": "1",
      "name": "item1"
    }
  },
  {
    "_type": "UpdateItem",
    "item": {
      "id": "1",
      "name": "item1-updated"
    }
  },
  {
    "_type": "DeleteAllItems"
  }
]

What if I'd like the "tag" property to be "type" instead of "_type", and the tag values to be snake case (ex: "add_item" instead of "AddItem")? To my knowledge that is not possible at the moment in V.

In Rust, using Serde's different enum representations, I can specify the attribute arguments tag and rename_all as follows:

#[derive(Serialize, Deserialize)]
#[serde(tag = "type", rename_all = "snake_case")]
enum Action {
    AddItem(AddItem),
    UpdateItem(UpdateItem),
    DeleteAllItems,
}

Which would produce the desired JSON format:

[
  {
    "type": "add_item",
    "item": {
      "id": "1",
      "name": "item1"
    }
  },
  {
    "type": "update_item",
    "item": {
      "id": "1",
      "name": "item1-updated"
    }
  },
  {
    "type": "delete_all_items"
  }
]

Another use-case would be wanting to use the "adjacently tagged" format instead of the "internally tagged" format that is currently produced by V.

Again using Rust as an example, I can add the Serde attribute argument content:

#[derive(Serialize, Deserialize)]
#[serde(tag = "type", content = "value", rename_all = "snake_case")]
enum Action {
    AddItem(AddItem),
    UpdateItem(UpdateItem),
    DeleteAllItems,
}

Which would produce:

[
  {
    "type": "add_item",
    "value": {
      "item": {
        "id": "1",
        "name": "item1"
      }
    }
  },
  {
    "type": "update_item",
    "value": {
      "item": {
        "id": "1",
        "name": "item1-updated"
      }
    }
  },
  {
    "type": "delete_all_items"
  }
]

One of the reason I'm asking is it would make working with existing APIs that use these formats to represent sum types (or discriminated unions) easier?

[jorgeluismireles]

Just an idea https://play.vlang.io/p/8ce5492e7b :

import json

struct Item {
	id   string   @[omitempty]
	name string   @[omitempty]
	action Action
}

enum Action {
	add
	update
	delete_all
}

fn main() {
	println(json.encode_pretty([
		Item{ id:'1', name:'item', action:.add },
		Item{ id:'1', name:'item1-updated', action:.update },
		Item{ action:.delete_all }
	]))
}

[{
		"id":	"1",
		"name":	"item",
		"action":	"add"
	}, {
		"id":	"1",
		"name":	"item1-updated",
		"action":	"update"
	}, {
		"action":	"delete_all"
	}]

[JalonSolov]

The type -> _type thing should be fixed. Probably leftovers from before V allowed using keywords as field names.

[jorgeluismireles]

To conform with your last json you could do this:

import json

struct Elem {
	typ   Type @[json:"type"]
	value Value @[omitempty]
}

struct Value {
	item Item
}

struct Item {
	id   string
	name string
}

enum Type {
	add_item
	update_item
	delete_all_items
}

println(json.encode_pretty([
	Elem{ typ:.add_item, value:Value{ item:Item{id:'1', name:'item1'}} },
	Elem{ typ:.update_item, value:Value{ item:Item{id:'1', name:'item1-updated'}} },
	Elem{ typ:.delete_all_items }
]))

[{
		"type":	"add_item",
		"value":	{
			"item":	{
				"id":	"1",
				"name":	"item1"
			}
		}
	}, {
		"type":	"update_item",
		"value":	{
			"item":	{
				"id":	"1",
				"name":	"item1-updated"
			}
		}
	}, {
		"type":	"delete_all_items"
	}]

[nicolashery]

Thank you for your replies @jorgeluismireles. I see you suggest using an enum instead of a sum type. Let me expand on my example a bit to better illustrate why I prefer to use a sum type:

• I will add a DeleteItem action that doesn't have the same shape as the CreateItem and UpdateItem actions, and is not an empty struct
• I will add a fn transform_action function that uses match which I think is one of the powerful feature of sum types (and granted, match also works with enums but we'll see why that doesn't provide the type safety I'd like in this particular case)

struct Item {
	id   string
	name string
}

struct AddItem {
	item Item
}

struct UpdateItem {
	item Item
}

struct DeleteItem {
	id string
}

struct DeleteAllItems {}

type Action = AddItem | UpdateItem | DeleteItem | DeleteAllItems

fn transform_action(action Action) string {
	return match action {
		AddItem {
			'add_item ${action.item.id} ${action.item.name}'
		}
		UpdateItem {
			'update_item ${action.item.id} ${action.item.name}'
		}
		DeleteItem {
			// type error: `DeleteItem` has no field named `item`
			'delete_item ${action.item.id}'
		}
		DeleteAllItems {
			'delete_all_items'
		}
	}
}

You can see that matching on the Action sum type, the compiler helps us avoid the mistake of calling action.item.id on a DeleteItem.

If I were to write this example using the enum pattern, I imagine it would look something like this:

module main2

enum ActionType {
	add
	update
	delete
	delete_all
}

struct Action {
	type ActionType
	item Item   @[omitempty]
	id   string @[omitempty]
}

struct Item {
	id   string
	name string
}

fn transform_action(action Action) string {
	return match action.type {
		.add {
			'add_item ${action.item.id} ${action.item.name}'
		}
		.update {
			'update_item ${action.item.id} ${action.item.name}'
		}
		.delete {
			// no type error!
			'delete_item ${action.item.id}'
		}
		.delete_all {
			'delete_all_items'
		}
	}
}

And in this case since Action is a struct that is a "bag" of possibly uninitialized values, the compiler can't help us avoid the mistake of calling action.item.id (instead of action.id) on a "delete item" action.

Thus my choice of using sum types as runtime representation, and my original question of being able to customize its JSON encoding/decoding.

[xxxserxxx]

This is still 2025, so I don't think it qualifies as a necrobump.

A real use case is jsonrpc, which is a defined standard and we don't have the luxury of changing the JSON format to suit V. jsonrpc results are defined (more or less, cut down) like this:

{ 
   "id": 5,
   "jsonrpc": "2.0",
   "result": {
      <string key with type name>: <serialized thing>
}

<string key with type name> varies with the result; it might align with V struct names, although it's almost always lower case: "server" could be struct Server {, "client" for struct Client {. The <serialized thing> is a straightforward json.encode(thing).

It's tantalizingly close to define an API like this:

struct First {
   name string
}
struct Second {
   quantity int
}
type Result = First | Second
struct Response {
   id int
   jsonrpc string
   result Result
}

because jsonrpc is going to give you:

{"id": 1, "jsonrpc": "2.0", "result": { "second": { "quantity": 23 } } }

But clearly, this does not work. r := json.decode(Response, str) always uses the first sum type, and tries to decode the object defined by "result" as the sum. So there are two issues, one of which might be a red herring

1. How to turn the <string key with type name> into a type
2. How to get the value of that attribute in result and decode it into the right sum type

1 may be a red herring; it's useless information unless it's used by the decoder to figure out the sum type. The API user usually doesn't care about it for jsonrpc, but for other APIs it might be important.

I think a solution would involve being able to put json attributes on structs, like this:

@[json: "first"]
struct First {
   name string
}

If the json encoder found such an attribute, it would serialize the struct as:

{ "first": { "name": "" } }

instead of

{"name": ""}

Similarly, the decoder would expect the first JSON instead of the second if it did find such an attribute on the type. This would solve both issues in one stroke with minimal language change.

Is there another solution that works with the assumption that the JSON representation provided by the server is not under our control?

[jorgeluismireles]

My two cents... I have a working jsonrpc go app. I found the easiest approach for the fields Req.params, Resp.result and Error.data was with go's any aka interface{}. Here are the three main objects and their fields:

type Req struct {
	Jsonrpc string  `json:"jsonrpc"` // should be 2.0
	Id      float64 `json:"id"`
	Method  string  `json:"method"`
	Params  any     `json:"params"`
}

type Resp struct {
	Jsonrpc string      `json:"jsonrpc"`          // should be 2.0
	Id      float64     `json:"id"`               // IMPORTANT don't set omitempty
	Result  interface{} `json:"result,omitempty"`
	Error   *Error      `json:"error,omitempty"`
}

type Error struct {
	Code    int    `json:"code"`
	Message string `json:"message"`
	Data    any    `json:"data,omitempty"`
}

I'll port this to V and I'll try the go's any V equivalent. I'll post what I get.