| > Type inference removes the need to specify types explicitly over and over. These days with C++11's auto, this is improved a lot. It's not full type inference, but eliminates most of the boilerplate, and arguably what's left you really want to keep for documentation purposes. > The object-oriented representation of a trivial sum type as an inheritance hierarchy of classes is needlessly inefficient. This use case strikes me as a particularly bad example of sum types: The author wants to represent different kinds of scene members, like spheres and groups, as a sum type. Using a sum type means that anyone wanting to add a new kind of object has to add it to the sum type and handle it everywhere, which will quickly become problematic. Using object-oriented design allows new object types to be introduced without updating everything. Basically the sum type looks nicer here only because it's a toy example and we're not considering how it will evolve. That said, I do think sum types are really useful in some use cases, especially in compilers, and I'm sad C++ doesn't have them. I tend to end up defining ASTs using Cap'n Proto as a convenient way to declare a tagged union, even though I have no intent to serialize the structures. > No need to write constructors for tuples, records and variant types in OCaml. To be fair, for an all-public struct (as in the example), you don't need constructors in C++ either. Once you have private members, then of course you need a constructor. > Native lists in OCaml. C++11 initializer lists make it basically possible to write list/vector/array classes that "feel native". > Higher-order functions instead of loops in OCaml. C++11 lambdas, etc. However, in a lot of cases, loops are easier to read. |
Would be nice to see Rust's Option<T> and Result<T,E> ported over to C++ since I find that error handling extremely elegant compared to most C++ approaches.