externally tagged enums

[dherman]

When you define an enum and derive Serialize or Deserialize, you might expect it to get the "externally tagged" semantics described by the serde documentation -- where each variant is represented as a table with a key named after the variant name. But AFAICT this representation doesn't work. Here's a simple example, a config format with a [main] section and a plugin field that can be one of { "url" = ...} or { "bin" = ... }:

extern crate toml;
#[macro_use]
extern crate serde_derive;
extern crate serde;

#[derive(Serialize, Deserialize, Debug)]
pub struct Config {
    pub main: Option<Main>
}

#[derive(Serialize, Deserialize, Debug)]
#[serde(rename = "main")]
pub struct Main {
    pub plugin: Option<Plugin>,
}

#[derive(Serialize, Deserialize, Debug)]
#[serde(rename_all = "lowercase")]
pub enum Plugin {
    Url(String),
    Bin(String)
}

const SRC: &'static str = "
[main]
plugin = { \"bin\" = \"echo 'hello'\" }
";

fn main() {
    match toml::from_str::<Config>(SRC) {
        Err(e) => { eprintln!("error: {}", e); }
        Ok(result) => { eprintln!("result: {:?}", result); }
    }

}

This fails to deserialize at runtime with the error "expected string for key main.plugin". I'm not sure why.

BTW there are workarounds, e.g. to use the untagged representation:

extern crate toml;
#[macro_use]
extern crate serde_derive;
extern crate serde;

#[derive(Serialize, Deserialize, Debug)]
pub struct Config {
    pub main: Option<Main>
}

#[derive(Serialize, Deserialize, Debug)]
#[serde(rename = "main")]
pub struct Main {
    pub plugin: Option<Plugin>,
}

#[derive(Serialize, Deserialize, Debug)]
#[serde(untagged)]
pub enum Plugin {
    Url { url: String },
    Bin { bin: String }
}

const SRC: &'static str = "
[main]
plugin = { \"bin\" = \"echo 'hello'\" }
";

fn main() {
    match toml::from_str::<Config>(SRC) {
        Err(e) => { eprintln!("error: {}", e); }
        Ok(result) => { eprintln!("result: {:?}", result); }
    }

}

[azriel91]

Hiya, so I ran into these use cases in one of my projects, and was wondering if you think this type of usage pattern should be accepted:

For the given types:

#[derive(Debug, Deserialize)]
struct Config {
    plain: MyEnum,
    // tuple: MyEnum,
    #[serde(rename = "struct")]
    structv: MyEnum,
    newtype: MyEnum,
    my_enum: Vec<MyEnum>,
}

#[derive(Debug, Deserialize)]
enum MyEnum {
    Plain,
    Tuple(i64, bool),
    NewType(String),
    Struct { value: i64 },
}

Accept the following:

plain = "Plain"
tuple = { 0 = 123, 1 = true }
struct = { Struct = { value = 123 } }
newtype = { NewType = "value" }
my_enum = [
    { Plain = {} },
    { Tuple = { 0 = 123, 1 = true } },
    { NewType = "value" },
    { Struct = { value = 123 } }
]

So far this is what I've got:

# toml
my_enum = "UnitVariant"                             # works with current toml crate
my_enum = { UnitVariant = {} }                      # implemented on #264
my_enum = { StructVariant = { field = "value" } }   # implemented on #264
my_enum = { NewTypeVariant = { "value" } }          # implemented on #264
my_enum = { TupleVariant = { 0 = 123, 1 = false } } # implemented on #264

# Ignore
my_enum = { TupleVariant = [123, false] }           # invalid TOML

[azriel91]

In terms of intuitiveness and "should we support it", I think it's something like this:

# intuitive, should support
my_enum = "UnitVariant"
my_enum = { StructVariant = { field = "value" } }
my_enum = { NewTypeVariant = { "value" } }

# not intuitive, should support
my_enum = { UnitVariant = {} } # necessary for a vector of enums

# not intuitive, maybe support
my_enum = { TupleVariant = { 0 = 123, 1 = false } }

# not intuitive, should not support
my_enum = "value" # for NewTypeVariant

[internally-combusted]

Does this kind of enum currently only work with the inline table syntax?

Given:

// Rust code
struct Vec2 {
    x: f32,
    y: f32,
}

struct TransformData {
    translation: Vec2,
    scaling: Vec2,
    rotation: f32,
}

enum ComponentData {
    Transform {
        transform_data: TransformData, 
    }
}

struct Component {
    data: ComponentData,
}

I can get something like this to deserialize:

# TOML
data = { Transform = { translation = { x = 100.0, y = 100.0 }, scaling = { x = 100.0, y = 100.0}, rotation = 1.0 } }

So the inline table format works, but unless I've misread something, inline tables have to be on a single line, so any non-trivial variant is going to be several screens long.

I've tried about seventeen different ways of using the [brackety] table syntax for the above, but I can't get anything to parse.

[ehuss]

@internally-combusted Unfortunately it looks like the enum support only handles inline tables.

[azriel91]

I've tried about seventeen different ways of using the [brackety] table syntax for the above, but I can't get anything to parse.

oh yes, attempted to get the full [table] syntax working, but had trouble understanding the code -- overwhelmed by too much information 🙁

[johansglock]

Ive opened a PR to get full tables working with enums. Feedback welcome to get this merged in!

[epage]

Maintenance of this crate has moved to the https://github.com/toml-rs/toml repo. As a heads up, we plan to move toml to be on top of toml_edit, see toml-rs/toml#340.

Closing this out. If this is still a problem, feel free to recreate this issue in the new repo.