Ergonomics of optional fields

[ozkriff]

If I have a struct like

#[derive(Debug, Clone, Deserialize)]
pub struct Settings {
    pub font: Option<PathBuf>, // <- optional field
    pub other_value: u8,
}

I can omit the field in .ron file to get None:

(
    other_value: 0,
)

But I'm forced to write Some() around the actual value which clutters up the config:

(
    font: Some("OpenSans-Regular.ttf"), // :(
    // font: "OpenSans-Regular.ttf", // I want this
    other_value: 0,
)

Seems like an ergonomic problem to me :(

See https://gitter.im/ron-rs/ron?at=59d228bd614889d47565733d

[torkleyy]

@ozkriff If you don't specify a font, you'll use some fallback, right?

[ozkriff]

Correct.

[torkleyy]

#[derive(Deserialize)]
struct Settings {
    #[serde(default = "default_font")]
    font: String,
}

fn default_font() -> String {
    "default.ttf".to_owned()
}

[ozkriff]

The problem in this specific case is that if there's no font in the config, I want to use embedded font:

let font = if let Some(ref fontpath) = settings.font {
    new_font_from_vec(fs::load(fontpath))
} else {
    let data = include_bytes!("Karla-Regular.ttf");
    new_font_from_vec(data.to_vec())
};

[kvark]

@ozkriff isn't it easy to workaround? set default to something like "<embedded>", then check for it and load your font correspondingly

[ozkriff]

@kvark yep, that's what I'm going to do. Though it's still a hack and I think I would prefer some kind of "(configurable) option promotion" from RON or something.

[torkleyy]

@kvark Do we want an option for implicit Some? And if so, should it be on by default?

[kvark]

@torkleyy I don't see a strong for it yet. The serde defaults should cover it mostly, and help keep ron simpler and more consistent.

[oraknabo]

I understand how it makes sense to work around it from the Rust side of things, but it does feel really counter-intuitive to have to wrap lots of values with Some() on the scripting side.

Even though the scripter should know whether a field is optional or not, I feel like it expects too much understanding of Rust. I've done something similar to with TOML in a previous project and it handled options implicitly. I don't mean to imply that you should do it just because they did, but it just felt more like the right way to do things from the scripting side of things.

Could the parser check to see if an option is expected and wrap the value with Some() automatically?

[torkleyy]

The current strategy was chosen because it is more concise. E.g. None could be None in Rust or Some(None).

[kvark]

I would like the current concise scheme to be default, but I don't mind an option in the new pragmas. There are more clients who want it (@ozkriff).

…

On Jan 13, 2018, at 12:41, Thomas Schaller ***@***.***> wrote: The current strategy was chosen because it is more concise. E.g. None could be None in Rust or Some(None). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[torkleyy]

I already started working on a solution, but couldn't finish it yet.

[oraknabo]

@kvark @torkleyy It just feels like the default behavior is a little inconsistent:

• I have optional_field: Option<String> in Rust.
• If I omit the field in a .ron file, it accepts it as None, no "expected option" error message.
• If I supply a String, I get an "expected option" error.

Shouldn't it see that I correctly supplied a String and accept it (same as with None) since String and None are both acceptable values for optional_field?

[torkleyy]

You can only skip the field if you added #[serde(skip)] .

[Boscop]

If missing fields become None, and existing fields become Some(val), that would mean the format won't be self-describing any longer, right?
I don't have a problem with that though, as it's intended to be written by humans..
But how to distinguish Some(None) from None etc? The same way as serde_json?