Live data from Hacker News

Type-Safe Unions in C++ and Rust

genbattle.bitbucket.org

21–30 of 140 posts

Re: Type-Safe Unions in C++ and Rust

#21

Note C++2017's std::variant is based upon boost::variant, which has been around since at least 2004 ( http://www.boost.org/doc/libs/1_31_0/doc/html/variant.html , http://www.boost.org/users/history/ ). boost::variant however lacks a nice visit method that takes lambdas, instead requiring the user to create visitor classes. This verbosity may be part of the reason it wasn't adopted in mass, in spite of its advantages…

They are implemented completely differently. The only real similarity is in the name and API. Boost variant suffers from significant performance penalties that the new std::variant does not have.

Boost.variant suffers for being correct by default (i.e. strongly exception safe) plus opt-in for speed, while the new std::variant can get in an invalid state if an exception is thrown at a bad time. Let's say that the trade-offs will be hotly debated until the standard actually ships.

Re: Type-Safe Unions in C++ and Rust

#22

Earlier quoted context omitted.

One interesting thing about Rust is that none of the language features are really new . Even the borrow checker is from research papers and languages from quite a while ago. The only thing I can think of that might be truly unique to Rust is the concurrency safety model (Send+Sync), though that might be old too. Rust has just managed to take all these features and put them together well, and strive to be more than a…

Yes, worth noting that this was an initial goal of Rust: to use research that was rarely implemented, but established and non-novel among CS academics. See http://tim.dreamwidth.org/1784423.html -- I remember some comment about this being part of the choice of the name, too, but I can't find anything specific or definitive about that.

The name "Rust" has so many origin stories; IIRC the creator kept changing the story each time he was asked :)

Re: Type-Safe Unions in C++ and Rust

#23

Earlier quoted context omitted.

They are implemented completely differently. The only real similarity is in the name and API. Boost variant suffers from significant performance penalties that the new std::variant does not have.

Boost.variant suffers for being correct by default (i.e. strongly exception safe) plus opt-in for speed, while the new std::variant can get in an invalid state if an exception is thrown at a bad time. Let's say that the trade-offs will be hotly debated until the standard actually ships.

The problem with Boost.variant is that all data is doubly allocated, including at least 1 heap allocation as a copy. This is not obvious and is certainly not what a lot of users would want. But you are right, it does this to avoid exceptional situations.

Re: Type-Safe Unions in C++ and Rust

#25

Earlier quoted context omitted.

They are implemented completely differently. The only real similarity is in the name and API. Boost variant suffers from significant performance penalties that the new std::variant does not have.

Boost.variant suffers for being correct by default (i.e. strongly exception safe) plus opt-in for speed, while the new std::variant can get in an invalid state if an exception is thrown at a bad time. Let's say that the trade-offs will be hotly debated until the standard actually ships.

The tradeoffs have been hotly debated for years :) The current spec is finally something the committee could agree on, after countless proposals, counter-proposals, endless email discussions and long evenings at committee meetings.

Re: Type-Safe Unions in C++ and Rust

#26
post #25

Earlier quoted context omitted.

Boost.variant suffers for being correct by default (i.e. strongly exception safe) plus opt-in for speed, while the new std::variant can get in an invalid state if an exception is thrown at a bad time. Let's say that the trade-offs will be hotly debated until the standard actually ships.

The tradeoffs have been hotly debated for years :) The current spec is finally something the committee could agree on, after countless proposals, counter-proposals, endless email discussions and long evenings at committee meetings.

I agree that the current spec is better than none at all, but it feels like a bad compromise. I would have preferred either a fully exception safe variant or one with an explicit empty state.

Re: Type-Safe Unions in C++ and Rust

#27
post #3

> but it’s the first language I’ve experimented with that has made them a first-class feature It is a feature of ALGOL68, Pascal, Ada and quite some newer languages: https://en.wikipedia.org/wiki/Tagged_union

I've come to the conclusion that most "modern advanced" features were actually in ALGOL.

Algebraic datatypes with (even just basic) pattern matching (preferably with compile-time exhaustiveness checking) are things I've wanted in C++ ten years ago. This gets me part of the way there, at least. :)

Re: Type-Safe Unions in C++ and Rust

#28
post #3

> but it’s the first language I’ve experimented with that has made them a first-class feature It is a feature of ALGOL68, Pascal, Ada and quite some newer languages: https://en.wikipedia.org/wiki/Tagged_union

They're specifically saying that it's the first language they've experimented with, not the first language in general, FFS.

Re: Type-Safe Unions in C++ and Rust

#29
post #20

Isn't this just an algebraic data structure?

well, yes. The nice thing is that in C++ can be implemented purely as a library. Sometimes C++ feels like the high level languages assembler.

> The nice thing is that in C++ can be implemented purely as a library.

The bad thing is that they suck.

Re: Type-Safe Unions in C++ and Rust

#30

Newbie here. What are the differences with Swift Enumerations?

Details (some features they provide or can provide), Swift's enumerations and Rust's enum are both implementation of the older concept of Algebraic Data Types (ADT), which can be found in pretty much any language inspired by ML (directly or indirectly).
Post reply on HN