{"id":754,"date":"2017-05-12T15:33:58","date_gmt":"2017-05-12T15:33:58","guid":{"rendered":"http:\/\/dlang.org\/blog\/?p=754"},"modified":"2021-10-08T11:11:24","modified_gmt":"2021-10-08T11:11:24","slug":"serialization-in-d","status":"publish","type":"post","link":"https:\/\/dlang.org\/blog\/2017\/05\/12\/serialization-in-d\/","title":{"rendered":"Serialization in D"},"content":{"rendered":"

Vladimir Panteleev has spent over a decade using and contributing to D. He is the creator and maintainer of DFeed<\/a>, the software powering the D forums, has made numerous contributions to Phobos<\/a>, DRuntime<\/a>, DMD<\/a>, and the D website<\/a>, and has created several tools useful for maintaining D software (like Digger<\/a> and Dustmite<\/a>).<\/em><\/p>\n

\n

\"\"A few days ago, I saw this blog post by Justin Turpin on the front page of Hacker News:<\/p>\n

The Grass is Always Greener – My Struggles with Rust<\/a><\/p>\n

This was an interesting coincidence in that it occurred during DConf<\/a>, where I had mentioned serialization in D a few times during my talk. Naturally, I was curious to see how D stands up to this challenge.<\/p>\n

The Task<\/h3>\n

Justin’s blog starts off with the following Python code:<\/p>\n

import configparser\r\nconfig = ConfigParser()\r\nconfig.read(\"config.conf\")<\/pre>\n
This is actually very similar to a pattern I use in many of my D programs. For example, DFeed<\/a> (the software behind forum.dlang.org<\/a>), has this code<\/a> for configuring its built-in web server:<\/p>\n
struct ListenConfig\r\n{\r\n    string addr;\r\n    ushort port = 80;\r\n}\r\n\r\nstruct Config\r\n{\r\n    ListenConfig listen;\r\n    string staticDomain = null;\r\n    bool indexable = false;\r\n}\r\nconst Config config;\r\n\r\nimport ae.utils.sini;\r\nshared static this() { config = loadIni!Config(\"config\/web.ini\"); }<\/pre>\n
This is certainly more code than the Python example, but that’s only the case because I declare the configuration as a D type. The loadIni<\/code> function then accepts the type as a template parameter and returns an instance of it. The strong typing makes it easier to catch typos and other mistakes in the configuration – an unknown field or a non-numeric value where a number is expected will immediately result in an error.<\/p>\n
On the last line, the configuration is saved to a global by a static constructor (shared<\/code> indicates it runs once during program initialization, instead of once per thread). Even though loadIni<\/code>‘s return type is mutable, D allows the implicit conversion to const<\/code> because, as it occurs in a static constructor, it is treated as an initialization.<\/p>\n
Traits<\/h3>\n
The Rust code from Justin’s blog is as follows:<\/p>\n
#[macro_use]\r\nextern crate serde_derive;\r\nextern crate toml;\r\n\r\n#[derive(Deserialize)]\r\nstruct MyConfiguration {\r\n  jenkins_host: String,\r\n  jenkins_username: String,\r\n  jenkins_token: String\r\n}\r\n\r\nfn gimme_config(some_filename: &str) -> MyConfiguration {\r\n  let mut file = File::open(some_filename).unwrap();\r\n  let mut s = String::new();\r\n  file.read_to_string(&mut s).unwrap();\r\n  let my_config: MyConfiguration = toml::from_str(s).unwrap();\r\n  my_config\r\n}<\/pre>\n
The first thing that jumps out to me is that the MyConfiguration<\/code> struct is annotated with #[derive(Deserialize)]<\/code>. It doesn’t seem optional, either – quoting Justin:<\/p>\n
This was something that actually really discouraged me upon learning, but you cannot implement a trait for an object that you did not also create. That’s a significant limitation, and I thought that one of the main reason Rust decided to go with Traits and Structs instead of standard classes and inheritance was for this very reason. This limitation is also relevant when you’re trying to serialize and deserialize objects for external crates, like a MySQL row.<\/p><\/blockquote>\n
D allows introspecting the fields and methods of any type at compile-time, so serializing third-party types is not an issue. For example (and I’ll borrow a slide from my DConf talk<\/a>), deserializing one struct field from JSON looks something like this:<\/p>\n
string jsonField = parseJsonString(s);\r\nenforce(s.skipOver(\":\"), \": expected\");\r\n\r\nbool found;\r\nforeach (i, ref field; v.tupleof)\r\n{\r\n    enum name = __traits(identifier, v.tupleof[i]);\r\n    if (name == jsonField)\r\n    {\r\n        field = jsonParse!(typeof(field))(s);\r\n        found = true;\r\n        break;\r\n    }\r\n}\r\nenforce(found, \"Unknown field \" ~ jsonField);<\/pre>\n
Because the foreach<\/code> aggregate is a tuple (v.tupleof<\/code> is a tuple of v<\/code>‘s fields), the loop will be unrolled at compile time. Then, all that’s left to do is compare each struct field with the field name we got from the JSON stream and, if it matches, read it in. This is a minimal example that can be improved e.g. by replacing the if<\/code> statements with a switch<\/code><\/a>, which allows the compiler to optimize the string comparisons to hash lookups.<\/p>\n
That’s not to say D lacks means for adding functionality to existing types. Although D does not have struct inheritance like C++ or struct traits like Rust, it does have:<\/p>\n