6 ms·

C++ has a philosophy of not doing anything with the language if it can be done in library. Now the question is : what can we improve in the language so it can

by fooker 1y ago

C++ has a philosophy of not doing anything with the language if it can be done in library. 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.

MattPalmer1086 1y ago
> C++ has a philosophy of not doing anything with the language if it can be done in library. 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.
- aw1621107 1y ago
  Preferring things to be done in a library is not mutually exclusive with adding features that require language support as well.
- fooker 1y ago
  > Then why is the language so ridiculously complicated? 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.
xigoi 1y ago
> C++ has a philosophy of not doing anything with the language if it can be done in library. Except all the OOP features, which absolutely needed dedicated syntax even though they could have been a library.
- fooker 1y ago
  True 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 - https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html
Sharlin 1y ago
Sum types are a fundamental feature of the type system, just like product types. C++ doesn't try to implement the concept of struct as a library abstraction, either. Or the `||` operator for that matter, even though it's always expressible with just `!` and `&&`.
- fooker 1y ago
  About product types, C++ does try to implement that as a library too (std::tuple), and the result is equally disastrous :) 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.
  - Sharlin 1y ago
    Sure, but my point was that user-defined nominal sum types (tagged unions such as Rust enums) are just as important as user-defined nominal product types (structs, records, classes). The concept of "one of these" is just as important as "all of these" in domain modeling. Proper support for algebraic data types is a force multiplier. 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.
    - fooker 1y ago
      The tagging part is easy, the tricky thing is to unify this concept with constructors and destructors. 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.

by fooker 1y ago

MattPalmer1086 1y ago

> C++ has a philosophy of not doing anything with the language if it can be done in library. 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.

aw1621107 1y ago
Preferring things to be done in a library is not mutually exclusive with adding features that require language support as well.
fooker 1y ago
> Then why is the language so ridiculously complicated? 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.

xigoi 1y ago

> C++ has a philosophy of not doing anything with the language if it can be done in library. Except all the OOP features, which absolutely needed dedicated syntax even though they could have been a library.

fooker 1y ago
True 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 - https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html

Sharlin 1y ago

Sum types are a fundamental feature of the type system, just like product types. C++ doesn't try to implement the concept of struct as a library abstraction, either. Or the `||` operator for that matter, even though it's always expressible with just `!` and `&&`.

fooker 1y ago
About product types, C++ does try to implement that as a library too (std::tuple), and the result is equally disastrous :) 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.
- Sharlin 1y ago
  Sure, but my point was that user-defined nominal sum types (tagged unions such as Rust enums) are just as important as user-defined nominal product types (structs, records, classes). The concept of "one of these" is just as important as "all of these" in domain modeling. Proper support for algebraic data types is a force multiplier. 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.
  - fooker 1y ago
    The tagging part is easy, the tricky thing is to unify this concept with constructors and destructors. 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.