5 ms·

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 suc

by fooker 1y ago

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.

ghosty141 1y ago
> 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.
- fooker 1y ago
  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.pdf https://www.stroustrup.com/pattern-matching-November-2014.pd...
- tialaramex 1y ago
  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.

by fooker 1y ago

ghosty141 1y ago

> 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.

fooker 1y ago
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.pdf https://www.stroustrup.com/pattern-matching-November-2014.pd...
tialaramex 1y ago
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.