Item — HN Reader

A lot of the problems with C++ are more foundational; you can't adopt the changes that newer languages have made, because that would be a new language - and we know this, because that new language's name is Carbon.

There are things you can add, but the rot still permeates the foundations, and much of the newness goes partially unused because they're just not at home in C++. Use of `std::optional` and `std::variant` is, as far as I know, still limited, even in newer C++ code, because the ergonomics just aren't there.

2 comments

optional is heavily used in new codebases.

variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic.

C++ does have quite a bit of rot, you're right. But that's the price of building technology people actually use.

Carbon doesn't seem to have any fundamentally new ideas, we'll see how well it fares in the wild.

> variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic.

Thats the fantastic thing about c++, you can already write an easy to use match, but they just chose not to include that in the stdlib but rather want you write that yourself.

Example:

    match(foo,
        [](Foo&) {
        },
        [&](Bar& bar) {
        },
        [&](const auto& mode) {
            // catch all
        });

Also optional and expected are ergonomic nightmares since there is no "try!" macro like rust has. In general it lacks the infrastructure that is needed to make these types nice to use. It also clashes with other concepts like RAII where you kinda have to use exceptions when it comes to ctors that may fail.

It would be pretty ugly to make this more introspective in C++.

For example, if you had to match patterns to distinguish between these three possibilities when looking at a tree: (val), (val (tree left) (tree right)), (val (tree subtree)). Here, the possibilities are not really separate types, but rather different ways of constructing a type. This sort of pattern shows up in general purpose programming (even meat and potato imperative programming) pretty often.

There was a proposal for this championed by Stroustrup over ten years ago, but it went nowhere IIRC. https://www.stroustrup.com/pattern-matching-November-2014.pd...

The try! macro was deprecated in 2019 so, almost six years ago. And even before formal deprecation the word try is now a keyword and so you'd need to use r#try! to say you want the obsolete macro not the keyword.

Ergonomics of std::optional and std::variant have nothing to do with bad foundations and all to do with the C++ committee insisting on these being library features rather than language features. I'm sure we will get the syntactic sugar eventually like we did get range-based for loops after having had to deal with macro approximations of foreach forever.

You’re right.

I have some hope that the upcoming compile time reflection will make it easier to implement said syntactic sugar.