Make it possible to deserialize a new type variant that contain None

[zetafunction]

Example snippet:

use serde::{Deserialize};

#[derive(Debug, Deserialize)]
struct S {
    value: ExampleEnum,
}

#[derive(Debug, Deserialize)]
enum ExampleEnum {
  Variant(Option<NestedEnum>),
}

#[derive(Debug, Deserialize)]
enum NestedEnum {
    NestedVariant,
}

fn main() {
    println!("{:?}", toml::from_str::<S>("value = { Variant = 'NestedVariant' }"));
    println!("{:?}", toml::from_str::<S>("value = { Variant = 'None' }"));
    println!("{:?}", toml::from_str::<S>("value = { Variant = '' }"));
    println!("{:?}", toml::from_str::<S>("value = { Variant = {}}"));
    println!("{:?}", toml::from_str::<S>("value = { Variant }"));
    println!("{:?}", toml::from_str::<S>("value = 'Variant'"));
}

Currently this prints:

Ok(S { value: Variant(Some(NestedVariant)) })
Err(TomlError { message: "unknown variant `None`, expected `NestedVariant`", raw: Some("value = { Variant = 'None' }"), keys: ["value"], span: Some(20..26) })
Err(TomlError { message: "unknown variant ``, expected `NestedVariant`", raw: Some("value = { Variant = '' }"), keys: ["value"], span: Some(20..22) })
Err(TomlError { message: "wanted exactly 1 element, found 0 elements", raw: Some("value = { Variant = {}}"), keys: ["value"], span: Some(20..22) })
Err(TomlError { message: "expected `.`, `=`", raw: Some("value = { Variant }"), keys: [], span: Some(18..19) })
Err(TomlError { message: "invalid type: unit variant, expected newtype variant", raw: Some("value = 'Variant'"), keys: ["value"], span: Some(8..17) })

It would be nice if there were some way for this to work. toml-lang/toml#1025 indicates there is no null/none value, but it'd still be nice to be able to deserialize this somehow. Perhaps there's just no nice way to do that though...

[epage]

To find how something should be formatted, I'd recommend serializing the data

Example snippet

use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize, Serialize)]
struct S {
    value: ExampleEnum,
}

#[derive(Debug, Deserialize, Serialize)]
enum ExampleEnum {
  Variant(Option<NestedEnum>),
}

#[derive(Debug, Deserialize, Serialize)]
enum NestedEnum {
    NestedVariant,
}

fn main() {
    let value = S {
        value: ExampleEnum::Variant(Some(NestedEnum::NestedVariant))
    };
    println!("{:?}", value);
    println!("{}", toml::to_string(&value).unwrap());
    let value = S {
        value: ExampleEnum::Variant(None)
    };
    println!("-------------------");
    println!("{:?}", value);
    println!("{:?}", toml::to_string(&value));
    println!("-------------------");
}

S { value: Variant(Some(NestedVariant)) }
[value]
Variant = "NestedVariant"

-------------------
S { value: Variant(None) }
Err(UnsupportedNone)
-------------------

So yes, in this case, it is unsupported. I am very cautious of assuming how something should be serialized or deserializes related to None. We do allow for empty tables in some specific cases because that was already done .

[sdasda7777]

Hi, do I understand correctly, that TOML has the expressive capabilities for this, and this is more of an issue with capabilities of this library, specifically in terms of serialization lookahead? Would it perhaps be possible for the user of the library to specify somehow that the Option should not be flattened. so that it would behave exactly like if you defined the Option type yourself? It's a little crude, but the current state is really not ideal either.

#[derive(serde::Serialize)]
enum MyOption<T: serde::Serialize> {
    Some(T),
    None,
}

fn main() {
    println!("{:?}", toml::Value::try_from(MyOption::Some(1))); // Ok(Table({"Some": Integer(1)}))
    println!("{:?}", toml::Value::try_from(MyOption::None::<u32>)); // Ok(String("None"))
}

In terms of deserialization of the original example, I think I would then expect something like this to work:

println!("{:?}", toml::from_str::<S>("value = { Variant = { Some = 'NestedVariant' } }"));
println!("{:?}", toml::from_str::<S>("value = { Variant = 'None' }"));

[epage]

TOML does not have the expressive capabilities for this because it does not have None/null. Anything we do is a workaround for that.

As for providing a way to specify Options behavior, we are limited by

• serde's API
• TOML syntax
• consistency with serde_json in how data is serialized

[sdasda7777]

TOML does not have the expressive capabilities for this because it does not have None/null.

Sorry, I'm probably missing something, but I don't see how the latter implies the former. As I've outlined, I think not flattening the Option would fix this, which would imply the issue is not with TOML, but rather the implementation not making/not being allowed to make proper use of it. Consistency is obviously a good thing, but if you have two formats with different capabilities, something's got to give, and this footgun is the result.

[sdasda7777]

I don't know if issuing a compiler warning/error when the Option is being used incorrectly is possible, but the fact that you can compile something that is expected to not work with no warnings is just maddening to me.

[epage]

Sorry, I'm probably missing something, but I don't see how the latter implies the former. As I've outlined, I think not flattening the Option would fix this, which would imply the issue is not with TOML, but rather the implementation not making/not being allowed to make proper use of it. Consistency is obviously a good thing, but if you have two formats with different capabilities, something's got to give, and this footgun is the result.

I stand by what I said. TOML cannot express this natively. Anything we do on top would be a hack that comes with many of its own problems. Treating Option like any other enum would also surprise people by the extra nesting, be harder to write, and would be incompatible with how serde_json serializes data.

Ideally, the following would have the same result:

• TOML derialized as a struct with an Option
• TOML deserialized to toml::Table then deserialized to a struct with an Option
• TOML deserialized to serde_json::Value then deserialized to a struct with an Option