|
|
|
|
|
|
by Rusky
1370 days ago
|
|
|
I mean, have you looked at them? C++'s standard library optional type is a tagged union implemented from scratch, with a dizzying array of template metaprogramming to meet the standard's requirements- see e.g. Microsoft's here: https://github.com/microsoft/STL/blob/main/stl/inc/optional#.... This isn't a criticism of the team behind this code, it's just what it takes to do this in C++. Rust gets most of that functionality from the language instead, in a much cleaner way. Sum types are built in, value categories and move semantics are handled automatically, there is little-to-no metaprogramming, and most of the API is just simple convenience combinators with obvious implementations: https://github.com/rust-lang/rust/blob/master/library/core/s... If nothing else, this is a clear counterexample to the claim that "Option and Result types are as easily coded in C++." |
|
|
Last time I looked at Rust's std::Result, it's implemented as a tagged union.
Most of C++'s implementations of a Result data type are implemented as tagged unions as well.
What's your point?
> This isn't a criticism of the team behind this code, it's just what it takes to do this in C++.
The only conceivable argument you can possibly make is argue that Rust might support tagged unions as language primitives, but that would be totally pointless as Result types are relevant for the interfaces and higher level abstraction they provide, not your personal opinion of how hard someone else had to work to implement them.
I've developed Result and Either types in a few languages, including C++, and the only hard thing about C++ is doing the usual homework to handle lvalur/revalue/revalue well.