{"id":1507,"date":"2018-03-29T14:00:40","date_gmt":"2018-03-29T14:00:40","guid":{"rendered":"http:\/\/dlang.org\/blog\/?p=1507"},"modified":"2021-10-08T11:04:46","modified_gmt":"2021-10-08T11:04:46","slug":"std-variant-is-everything-cool-about-d","status":"publish","type":"post","link":"https:\/\/dlang.org\/blog\/2018\/03\/29\/std-variant-is-everything-cool-about-d\/","title":{"rendered":"std.variant Is Everything Cool About D"},"content":{"rendered":"

Jared Hanson has been involved with the D community since 2012, and an active contributor since 2013. Recently, he joined the Phobos team and devised a scheme to make it look like he’s contributing by adding at least 1 tag to every new PR. He holds a Bachelor of Computer Science degree from the University of New Brunswick and works as a Level 3 Support Engineer at one of the largest cybersecurity companies in the world.<\/em><\/p>\n

\n

\"\"I recently read a great article by Matt Kline<\/a> on how std::visit is everything wrong with modern C++<\/a>. My C++ skills have grown rusty from disuse (I have long since left for the greener pastures of D), but I was curious as to how things had changed in my absence.<\/p>\n

Despite my relative unfamiliarity with post\u20132003 C++, I had heard about the addition of a library-based sum type in\u00a0std<\/code> for C++17. My curiosity was mildly piqued by the news, although like many new additions to C++ in the past decade, it\u2019s something D has had for years<\/a>. Given the seemingly sensational title of Mr. Kline\u2019s article, I wanted to see just what was so bad about std::visit<\/code>, and to get a feel for how well D\u2019s equivalent measures up.<\/p>\n

My intuition was that the author was exaggerating for the sake of an interesting article. We\u2019ve all heard the oft-repeated criticism that C++ is complex and inconsistent (even some of its biggest proponents<\/a> think so), and it is<\/em> true that the ergonomics of templates in D are vastly improved over C++. Nevertheless, the underlying concepts are the same; I was dubious that std::visit<\/code> could be much harder to use than std.variant.visit<\/code>, if at all.<\/p>\n

For the record, my intuition was completely and utterly wrong.<\/p>\n

Exploring std.variant<\/h2>\n

Before we continue, let me quickly introduce D\u2019s std.variant<\/a> module. The module centres around the Variant<\/a> type: this is not actually a sum type like C++\u2019s std::variant<\/code>, but a type-safe container that can contain a value of any type. It also knows the type of the value it currently contains (if you\u2019ve ever implemented a type-safe union, you\u2019ll realize why that part is important). This is akin to C++\u2019s std::any<\/code> as opposed to std::variant<\/code>; very unfortunate, then, that C++ chose to use the name variant<\/code> for its implementation of a sum type instead. C\u2019est la vie.<\/em> The type is used as follows:<\/p>\n

import std.variant;\r\n\r\nVariant a;\r\na = 42;\r\nassert(a.type == typeid(int));\r\na += 1;\r\nassert(a == 43);\r\n\r\nfloat f = a.get!float; \/\/convert a to float\r\nassert(f == 43);\r\na \/= 2;\r\nf \/= 2;\r\nassert(a == 21 && f == 21.5);\r\n\r\na = \"D rocks!\";\r\nassert(a.type == typeid(string));\r\n\r\nVariant b = new Object();\r\nVariant c = b;\r\nassert(c is b); \/\/c and b point to the same object\r\nb \/= 2; \/\/Error: no possible match found for Variant \/ int<\/pre>\n
Luckily, std.variant<\/code> does<\/em> provide a sum type as well: enter Algebraic<\/a>. The name Algebraic<\/code> refers to algebraic data types<\/a>, of which one kind is a \u201csum type\u201d<\/a>. Another example is the tuple, which is a \u201cproduct type\u201d.<\/p>\n
In actuality, Algebraic<\/code> is not a separate type from Variant<\/code>; the former is an alias<\/a> for the latter that takes a compile-time specified list of types. The values which an Algebraic<\/code> may take on are limited to those whose type is in that list. For example, an Algebraic!(int, string)<\/code> can contain a value of type int<\/code> or string<\/code>, but if you try to assign a string<\/code> value to an Algebraic!(float, bool)<\/code>, you\u2019ll get an error at compile time. The result is that we effectively get an in-library sum type for free! Pretty darn cool. It\u2019s used like this:<\/p>\n
alias Null = typeof(null); \/\/for convenience\r\nalias Option(T) = Algebraic!(T, Null);\r\n\r\nOption!size_t indexOf(int[] haystack, int needle) {\r\n    foreach (size_t i, int n; haystack)\r\n        if (n == needle)\r\n            return Option!size_t(i);\r\n    return Option!size_t(null);\r\n}\r\n\r\nint[] a = [4, 2, 210, 42, 7];\r\nOption!size_t index = a.indexOf(42); \/\/call indexOf like a method using UFCS\r\nassert(!index.peek!Null); \/\/assert that `index` does not contain a value of type Null\r\nassert(index == size_t(3));\r\n\r\nOption!size_t index2 = a.indexOf(117);\r\nassert(index2.peek!Null);<\/pre>\n
The peek<\/code> function takes a Variant<\/code> as a runtime argument, and a type T<\/code> as a compile-time argument. It returns a pointer to T<\/code> that points to the Variant<\/code>\u2019s contained value iff<\/em> the Variant<\/code> contains a value of type T<\/code>; otherwise, the pointer is null<\/code>.<\/p>\n
Note:<\/strong> I\u2019ve made use of Universal Function Call Syntax<\/a> to call the free function indexOf<\/code> as if it were a member function of int[]<\/code>.<\/em><\/sup><\/p>\n
In addition, just like C++, D\u2019s standard library has a special visit<\/code> function that operates on Algebraic<\/code>. It allows the user to supply a visitor for each type of value the Algebraic<\/code> may hold, which will be executed iff<\/em> it holds data of that type at runtime. More on that in a moment.<\/p>\n
To recap:<\/h2>\n