Roughly following the discussion from https://github.com/ron-rs/ron/issues/47 and related issues and PRs, this PR extends the Number type (and so indirectly the Value type) to support integers. I hope I didn't grossly misunderstand the discussion there, but I am keen to make adjustments here to make the project better.

~~I tried to limit the impact to the API to a single breaking change by extending the already opaque Number type rather than the Value enum which exposes its structure. The breaking change is that the get method in Number is replaced by as_f64 and as_i64 for getting the appropriate type.~~ Since Integer and Float types are distinct, they will not be ordered by value (as explained below). This is a breaking change in itself.

To maintain the traits on Number, Integers are simply ordered before Floats. This makes float and integer not comparable in value (e.g. Number::Integer(2) < Number::Float(Float(1.0))) because I didn't see any necessity to do so, but I'm open to suggestions.

The tests are adjusted to verify that both integers and floats are working.

Makes the Serializer struct generic over io::Write, allowing it to be used with more types (and less allocation). As a side-effect, the trailing commas are also removed from the output.

This was a quick implementation, written in response to compiler messages, so it could probably do with some cleaning up. It might be a good time to approach #175

Closes #202

TODO

• [ ] Update docs

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

Would it be possible/reasonable to skip the surrounding (), {}, or [] on the top level structure in document? As it is a config needs to be saved as something like:

(
    player_name: "abc",
    foo: 5,
    bar: [
        1,
        5,
        22,
    ],
)

It'd be a lot cleaner to my mind if we could skip the surrounding brackets and just write it as:

player_name: "abc",
foo: 5,
bar: [
    1,
    5,
    22,
],

With the following struct, small will be represented as an array of u8 and large as a base64 String.

extern crate serde_derive;

extern crate serde;
extern crate serde_bytes;

#[derive(Serialize, Deserialize)]
struct BytesStruct {
    small: Vec<u8>,
    #[serde(with = "serde_bytes")]
    large: Vec<u8>,
}

Updates the requirements on base64 to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Followup to #393

Adds explicit variants in ron::Error for serde errors from serde::de::Error (serde::ser::Error only has the Error::custom method).

• [x] I've included my change in CHANGELOG.md

I'm seeing a pretty printing regression in 0.6 from 0.5; looks to be in nested arrays and structs?

E.g., seeing this in diffs now:

+                ),            ],
+        )),    ],

I believe a newline is missing after the ),, since adding a newline after yields the expected pretty printed string:

                ),
            ],
        )),
    ],

We need #335 to land on crates. There may potentially be other things that could be included. @MomoLangenstein or @torkleyy - would you be interested in driving the patch release?

This PR includes the implementation for compact arrays from #299 (stale and quite tricky to rebase), and a fix for #290 to make the pretty RON prettier. Specifically, this means that:

• pretty tuples and arrays will now use a separator string after , when multiline is disabled
• pretty structs and maps will now use a separator string after : and ,
• this separator string is a single space by default

• [x] I've included my change in CHANGELOG.md

Specifically, unwrap_newtypes would be great to have for serialization as well as deserialization.

This is especially relevant because serde recommends the "unwrapped" newtype representation, and ron is the odd one out in considering them semantically meaningful.

How should Some be treated in the presence of the unwrap_variant_newtypes extension? With that extension, NewtypeVariant(Some(a: 42, b: 24)) already worked, but Some(a: 42, b: 24) did not. In my opinion Some is just a newtype variant and should parse consistently here. @torkleyy what are your thoughts?

• [x] I've included my change in CHANGELOG.md

Is it possible to

1. read a config
2. prettyprint the ron::Value, while maintaining all struct names
3. optionally convert the struct names to a tag when converting to serde_json::Value

Fixes #115 by allowing ron maps to be deserialised from structs. This is a hack. I am very unsure if this is something we want ron to support with serde's current model, or if we wanted to hold out for some extension to serde that would give Deserializer's more control about how to handle things like flatten and untagged enums etc.

• [ ] I've included my change in CHANGELOG.md

Just to start tracking all the Value related ones - I'll try to tackle them in 0.9:

• [ ] #357
• [ ] #328
• [ ] #255
• [ ] #217
• [ ] #189
• [ ] #140
• [ ] #122
• [ ] #115
• [x] #407

Oh, I see! The MSRV on 0.7 is still 1.36 anyways.

How will we handle such breakage in the future?

Originally posted by @MomoLangenstein in https://github.com/ron-rs/ron/issues/383#issuecomment-1159623984