RON is a simple readable data serialization format that looks similar to Rust syntax. It's designed to support all of Serde's data model, so structs, enums, tuples, arrays, generic maps, and primitive values.

GameConfig( // optional struct name
    window_size: (800, 600),
    window_title: "PAC-MAN",
    fullscreen: false,

    mouse_sensitivity: 1.4,
    key_bindings: {
        "up": Up,
        "down": Down,
        "left": Left,
        "right": Right,

        // Uncomment to enable WASD controls
        /*
        "W": Up,
        "S": Down,
        "A": Left,
        "D": Right,
        */
    },

    difficulty_options: (
        start_difficulty: Easy,
        adaptive: false,
    ),
)

• Numbers: 42, 3.14, 0xFF, 0b0110
• Strings: "Hello", "with\\escapes\n", r#"raw string, great for regex\."#
• Byte Strings: b"Hello", b"with \x65\x73\x63\x61\x70\x65\x73\n", br#"raw, too"#
• Booleans: true, false
• Chars: 'e', '\n'
• Optionals: Some("string"), Some(Some(1.34)), None
• Tuples: ("abc", 1.23, true), ()
• Lists: ["abc", "def"]
• Structs: ( foo: 1.0, bar: ( baz: "I'm nested" ) )
• Maps: { "arbitrary": "keys", "are": "allowed" }

Note: Serde's data model represents fixed-size Rust arrays as tuple (instead of as list)

RON also supports several extensions, which are documented here.

RON's formal and complete grammar is available here.

There also is a very basic, work in progress specification available on the wiki page.

{
   "materials": {
        "metal": {
            "reflectivity": 1.0
        },
        "plastic": {
            "reflectivity": 0.5
        }
   },
   "entities": [
        {
            "name": "hero",
            "material": "metal"
        },
        {
            "name": "monster",
            "material": "plastic"
        }
   ]
}

Scene( // class name is optional
    materials: { // this is a map
        "metal": (
            reflectivity: 1.0,
        ),
        "plastic": (
            reflectivity: 0.5,
        ),
    },
    entities: [ // this is an array
        (
            name: "hero",
            material: "metal",
        ),
        (
            name: "monster",
            material: "plastic",
        ),
    ],
)

Note the following advantages of RON over JSON:

• trailing commas allowed
• single- and multi-line comments
• field names aren't quoted, so it's less verbose
• optional struct names improve readability
• enums are supported (and less verbose than their JSON representation)

[dependencies]
ron = "0.8"
serde = { version = "1", features = ["derive"] }

use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize, Serialize)]
struct MyStruct {
    boolean: bool,
    float: f32,
}

fn main() {
    let x: MyStruct = ron::from_str("(boolean: true, float: 1.23)").unwrap();

    println!("RON: {}", ron::to_string(&x).unwrap());

    println!("Pretty RON: {}", ron::ser::to_string_pretty(
        &x, ron::ser::PrettyConfig::default()).unwrap(),
    );
}

RON is not designed to be a fully self-describing format (unlike JSON) and is thus not guaranteed to work when deserialize_any is used instead of its typed alternatives. In particular, the following Serde attributes only have limited support:

• #[serde(tag = "tag")], i.e. internally tagged enums ¹
• #[serde(tag = "tag", content = "content")], i.e. adjacently tagged enums ¹
• #[serde(untagged)], i.e. untagged enums ¹
• #[serde(flatten)], i.e. flattening of structs into maps ²

While data structures with any of these attributes should generally roundtrip through RON, some restrictions apply ³ and their textual representation may not always match your expectation:

• flattened structs are only serialised as maps and deserialised from maps
• struct names inside an internally (or adjacently) tagged or untagged enum, e.g. by enabling the PrettyConfig::struct_types setting, are not supported
• enabling the #![enable(implicit_some)] extension on a document with internally (or adjacently) tagged or untagged enums is not supported
• untagged tuple / struct variants with no fields are not supported
• untagged tuple variants with just one field (that are not newtype variants) are not supported when the #![enable(unwrap_variant_newtypes)] extension is enabled
• internally tagged newtype variants must not contain a unit / unit struct inside an untagged newtype variant, or an untagged unit variant
• serde does not yet support i128 and u128 inside internally (or adjacently) tagged or untagged enums
• newtypes and zero-length arrays / tuples / tuple structs / structs / tuple variants / struct variants are not supported inside internally (or adjacently) tagged or untagged enums
• externally tagged tuple variants with just one field (that are not newtype variants) are not supported inside internally (or adjacently) tagged or untagged enums

Please file a new issue if you come across a use case which is not listed among the above restrictions but still breaks.

While RON guarantees roundtrips like Rust -> RON -> Rust for Rust types using non-deserialize_any-based implementations, RON does not yet make any guarantees about roundtrips through ron::Value. For instance, even when RON -> Rust works, RON -> ron::Value -> Rust, or RON -> ron::Value -> RON -> Rust may not work. We plan on improving ron::Value in an upcoming version of RON, though this work is partially blocked on serde#1183.

RON is dual-licensed under Apache-2.0 and MIT.

Any contribution intentionally submitted for inclusion in the work must be provided under the same dual-license terms.