Ability to configure Deserializer to enable extensions when parsing

[Boscop]

Problem: I want #![enable(unwrap_newtypes, implicit_some)] to be the default, and don't want my users to require to write it in every RON file.

Current workaround: Inject that line before parsing. It's suboptimal because I can't use BufReader and if there's a parsing error, the reported line number will be wrong from the user's POV.

Proposed Solution: Ability to configure Deserializer to enable extensions before parsing.

[kvark]

That seems plausible.

[toyboot4e]

I'd like this feature if #319 comes!

Just exposing Extensions might be enough:

impl<'de> Deserializer<'de> {
    pub fn exts(&self) -> &Extensions {
        &self.bytes.exts
    }

    pub fn exts_mut(&mut self) -> &mut Extensions {
        &mut self.bytes.exts
    }
}

[torkleyy]

I do understand why this is needed, but at the same time I don't like that, with this implemented, RON files can't be read by themselves; you need to know what extensions they are parsed with.

[kvark]

We have 2 models here: the original typed model, where you need to know the types being deserialized, and the value model, where RON is read opaquely. Having this feature seems to be in line with the typed model, but will block the value model.

[kvark]

Maybe files that rely on some extensions by default should just be named differently as a convention? like .ronx

[torkleyy]

I've been thinking about this issue a lot and my own conclusion is:

What are RON extensions?

RON extensions, right now, are deserialization options that are configured together with the deserialized data (in the .ron file). They do not influence parsing of RON - the syntax always stays the same.

Considerations

Knowing a Rust type, one might have certain expectations about how to write correct RON for it.

However, that's not all there is to it: What RON is correct and what isn't is completely controlled by what deserialization code serde comes up with. If I were to use a different deserialization library I might have to write different RON for it (e.g. it might not accept a RON tuple when a fixed-size array is expected).

Now that means that we have two options to control deserialization:

1. Configuring what the RON deserializer tells serde, in terms of serde's type model (RON -> serde, RON extensions)
2. Configuring how serde transforms "serde data" to Rust structures (serde -> Rust, serde attributes)

As it turns out, there are many options in serde to control deserialization (https://serde.rs/attributes.html). Now, does that mean RON extensions are unnecessary because we can achieve the same thing with serde? Some examples:

implicit_some

Could be replaced by serde attributes by implementing a custom visitor which visits deserialize_any and forwards deserialization to the type wrapped in Option. I think it would be possible to implement a generic module which can be used like this:

#[derive(Deserialize)]
struct Foo {
    #[serde(with = "implicit_some")]
    x: Option<i32>
}

other extensions

I was gonna look at each extension, but it seems that the same applies all the other extensions; they could be replaced in a similar fashion.

Are serde attributes a true replacement?

They are not the same. Some differences:

• Requires access to the code with the derive
• Possibly tedious to add all those attributes
• No longer can the author of the RON file choose for themselves how explicit they want to be in terms of options, newtypes, etc (the developer makes the decision for them)

Conclusion

With all of that in mind, and because it is not a change in syntax it does seem fine to me to configure the deserializer to behave differently (enable extensions from Rust).

However, contrary to serde attributes, there is one potential disadvantage: One must take care to configure the same extensions for deserialization and serialization, otherwise roundtripping will not work.

Unresolved questions

Should the extension syntax be deprecated if we choose to implement this? If yes, RON files can no longer use different deserialization options.

---

Please, share your opinions on this :)

[juntyr]

This is now (#343) possible with Options::default().with_default_extensions(<Extensions>).from_str("RON")