1. 4
  1.  

  2. 1

    It’s not clear what point the author is trying to make here. The article just ends without a conclusion.

    The closest thing to a conclusion is the summary:

    Sum types are one of my favourite features of Haskell and once you’ve used them it’s difficult to come back to a language without them, they are a useful tool that provides excellent safety and expressive power. They’re so useful that more and more languages are adopting them and it’s even possibile to implement them in C, with some caveats. As a side note, in C++ they could be implemented using a class with virtual members, by using the visitor pattern, using variant types or by using a templated class.

    which is not a conclusion, just a summary of what the blog post already says.

    I think it’s pretty strange to talk about it being ‘possible to implement sum types in C’. It may be, but the author hasn’t done so. He’s implemented natural numbers inefficiently, and implemented linked lists inefficiently, but hasn’t safely implemented any non-trivial sum types and certainly hasn’t implemented sum types in general in C.

    It’s like saying ‘you can implement monads in C++’ and then proving this by showing the existence of std::optional and std::forward_list. Implementing monads doesn’t mean having things that you can in theory write monad instances for, it means having the machinery to actually write those monad instances. Similarly, implementing sum types doesn’t mean writing a tagged union (something people were doing in C decades before Haskell existed), it means being able to declare a ‘sum type’ of some kind.

    With some template metaprogramming (easier than you think) it’s definitely possible to do so in C++, on both counts. Not in C. But you wouldn’t want to in C. That’s not the point of C. Trying to do this in C is like trying to do pointer arithmetic in Haskell. You might be able to weirdly emulate it in some way, and it’s cool to know that you can, but it’s not useful in practice.