> * structural pattern matching
Yes, but that has to come with proper sum types. std::variant doesn’t quite cut it.
I’d also absolutely require a simpler lambda syntax. The current one is terrible for one-liner lambdas.
Yes, but that has to come with proper sum types. std::variant doesn’t quite cut it.
I’d also absolutely require a simpler lambda syntax. The current one is terrible for one-liner lambdas.
Now the question is : what can we improve in the language so it can allow you to define a sum type better and more usable compared to std::variant?
This is a surprisingly difficult question to answer, hence we haven’t had progress there.
Then why is the language so ridiculously complicated? I had the most fun working with it back in around 2000, and even then it was quite insane. A lot has been added since then.
Mainly as an effort to not drop compatibility with 30 years old code. You could cut the C++ standard in half if not for this.
Except all the OOP features, which absolutely needed dedicated syntax even though they could have been a library.
You can design a pretty decent version if your users are willing to write a tiny bit of boilerplate.
In fact, the LLVM project sort of does this, for the sake of compiling with -fno-rtti
I don’t really disagree with you, but consider that one of the main goals of an object oriented language is to allow you to define custom types.
OOP chose to implement "one of" with subclasses and runtime polymorphism, but that's not really "one of these choices" but "one of an arbitrarily large space of choices" because OOP interfaces are extensible by design. You can add support for "sealed" interfaces, but at that point you basically have tagged unions with a very clumsy syntax (and bad performance depending on your object model).
C, of course, has `union`, which is what you'd expect from C: a very basic, very error-prone building block for DIY tagged unions. C++ improved (depending on who you ask) on C structs by adding privacy control, methods, and so on. Similarly C++ should improve on C unions by adding implicit tagging, soundness, exhaustivity analysis and so on, so that nobody has to write `class X { enum { a_, b_ } tag; union { A a; B b; }; }` and all the associated ceremony ever again.
Like Haskell, you’d want different tags to be constructed by different constructors. But it’s unclear how this will integrate with destructors, RAII, and inheritance.