Valuable: Enum Representations

[fosskers]

Feature Request

Crates

tracing-subscriber (I think)

Motivation

Currently, plain variants of enums like:

enum Colour
  Red,
  Green,
  Blue,
}

serialise with the json / valuable features like so:

{"Red": []}

as a full JS object with an empty list, presumably to accommodate potential inner fields for variants that have them. Upstream logging / monitoring platforms have been observed to not play well with this representation, rendering it strangely or deleting it entirely as "empty data".

Serde supports multiple Enum Representations. Indeed, the default is to just render the variant name as-is, as can be seen here:

#[derive(Debug, serde::Serialize)]
enum Colour {
    Red,
    Green,
    Blue,
}

fn main() {
    let c = Colour::Red;
    let json = serde_json::to_string(&c).unwrap();
    println!("{json}");
}

Red

Proposal

It depends on how this representation is viewed. If the current representation is deemed a bug, then the default output could simply be altered in the case of variants that contain no inner fields.

On the other hand, in the spirit of tokio-rs/valuable#75 , this could be considered an opportunity to provide greater control over how enums are represented as JSON.

In the short term, my person vote is for the former, but would like to see the latter implemented eventually as well.

Alternatives

Changing the default representation for the fieldless case may surprise current users who currently depend on it. There's no way to know if anybody currently does, however.

Another alternative would be to return to something that was explicitly avoided in the original announcement, namely general logging support for anything that has serde::Serialize .