Why should C++ as an imperative/OOP language ape everything possible in FP? It feels like when FP languages slap on OOP for a change. C++ wasn't designed with what we call FP these days in mind, so unless it's going to change drastically, there will always be "smell".
FP doesn't have many things C++/D etc. have. Should we insist on every FP to have assembly-level access, custom memory managers etc. because they are cool as well?
It doesn't need to ape everything possible in every FP language. Just sum types. To me, "closed type hierarchies" are a pretty fundamental thing in programming regardless of how they are represented (OO style subclasses or otherwise), perhaps more important and fundamental than other FP things such as closures/lambdas (which Java, C# and C++ all adopted).
It's already possible to make the class hierarchy in most/all OO languages but it takes 150 lines for what can be expressed in 5 with some help from the language. Most importantly, without lang support the compiler can't validate exhaustive matching.
Sum types are not "everything possible in FP". I'm part of the group that views sums as an extremely basic language feature and I give an extreme side-eye to any language that still doesn't have them in the current year.
> I'm part of the group that views sums as an extremely basic language feature
More importantly it's the second category of type relations. There are product types and there are sum types, if you only have product types, you're missing an entire half of expressible type relations/compositions.
It's not a matter of functional versus imperative, there's nothing inherently functional about sum types.
All OO languages have sum types in a way, but it's just not a very good way. If there is no data or only integer data it's usually called "enum" and if it's a more complex data structure then it's a class hierarchy. It's just really clumsy in most OO languages to type out "type PaymentMethod = Cash | CreditCard(CardDetails d) | Invoice(Address a)"
In OO it's "abstract class PaymentMethod" and then another 100 lines, plus probably a horrible visitor pattern (because you don't want the payment method handling the payment). This to just define the type, no actual payment logic.
Huge amounts of boilerplate, and very little power if the compiler can't ensure exhaustive matching.
FP doesn't have many things C++/D etc. have. Should we insist on every FP to have assembly-level access, custom memory managers etc. because they are cool as well?