Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

I agree completely with everything in this article. But in addition, I think std::variant also misses the point of sum types in a big way.

Sum types don't just store values of different types. They store different states, with associated data. So, for instance, consider the following simplistic expression AST; how would you store it in a std::variant?

    enum Expr {
        Number(usize),
        Negate(Expr),
        Add(Expr, Expr),
        Sub(Expr, Expr),
        Let(String, Expr, Expr),
        Var(String),
    }

View on HN

The C++17 equivalent would be something like the following (not tested):

  using NumberExpr = int;
  using VarExpr = std::string;
  struct AddExpr;

  using Expr = std::variant<NumberExpr, AddExpr, VarExpr>;

  struct AddExpr {
    std::unique_ptr<Expr> a;
    std::unique_ptr<Expr> b;
  }

Of course, this being C++, you need forward declarations and a firm grasp of the rules of incomplete types to be confident about declaring a simple AST type.

To completely address JoshTriplett's point, yes, you can just define another struct for the SubExpr variant to disambiguate it from the AddExpr case.

Requiring this kind of wrapping is awkward compared to e.g. Rust or Haskell's treatment of sum types, which unlike C++17 and std::visit both have powerful pattern matching features built into the language. Saying this as someone who writes C++ all day: std::visit and std::variant are weaksauce.

On the other hand, the C++ way gives you an actual type for each element of the sum; you can write a function which only takes AddExpr. The Rust way doesn't (yet).

Given that you have to define those types manually, I don't see why you couldn't do the same in Rust; it just doesn't force you to if you don't need it

That's rather disingenuous, because Haskell forces you to use `newtype` wrappers for lots of things you shouldn't need them for and don't need them for in C++.

Can you name an instance in Haskell where newtype is conceptually unnecessary but required by the language? In the sense that you may be able to derive the same set of logical guarantees that newtype gets you without using it, in principle.

Boosts variant library has a solution to this problem

http://www.boost.org/doc/libs/1_65_1/doc/html/variant/tutori...

    boost::variant<
        int,
        boost::recursive_wrapper<binary_op<add>>,
        boost::recursive_wrapper<binary_op<sub>>
    > expression;

When the visitor is applied, the recursive wrappers are unwrapped transparently.

> Sum types don't just store values of different types.

That's exactly what a tagged union does. std::variant is a tagged union. I was not aware of the name 'sum type' but it's supposed to be a synonim for a tagged union. Guess not, but std::variant is not meant as what you describe[1].

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n454...

> That's exactly what a tagged union does. std::variant is a tagged union.

Not exactly. std::variant is one particular type of a tagged union, where the only discriminant is the type. You can also have a tagged union where the discriminant determines some semantic state, and multiple such states may store the same type of value. That's still a sum type, still a tagged union, and not something std::variant can do.

Thanks for the clarification. This article also helped. http://talesofcpp.fusionfenix.com/post-21/rant-on-the-stdexp...

In it's terminology, std::variant is a 'discriminated union' instead of a 'sum type'. Making std::variant the latter would also have had disadvantages it seems.

You need to wrap the recursive references to Expr in boxes, or you'll have an infinitely sized type.

Sure. I was loosely borrowing syntax to give an example, and didn't want to go into that detail.

Well, the answer is you need a new type for every option in your list. That's not a massively satisfactory answer, but it is the answer...

Reading the article, it seems the committee just doesn't want to change the actual syntax of the language since C++11. The only reason I can think of is that it's easier for compiler vendors to update the STL and minor syntax changes rather than adding something like described in parent.

> values... states... data

Aren't these the same thing?

Reply on news.ycombinator.com