3 ms·

> C++'s option and result types are much larger, uglier, and harder to use correctly than Rust's. What's your rationale for claiming in a swiping generalizatio

> C++'s option and result types are much larger, uglier, and harder to use correctly than Rust's. What's your rationale for claiming in a swiping generalization that implementing a data type, regardless of all options or approaches and design, has no other option than doing everything wrong?

Rusky 4y ago
I mean, have you looked at them? C++'s standard library optional type is a tagged union implemented from scratch, with a dizzying array of template metaprogramming to meet the standard's requirements- see e.g. Microsoft's here: https://github.com/microsoft/STL/blob/main/stl/inc/optional#L214 https://github.com/microsoft/STL/blob/main/stl/inc/optional#.... This isn't a criticism of the team behind this code, it's just what it takes to do this in C++. Rust gets most of that functionality from the language instead, in a much cleaner way. Sum types are built in, value categories and move semantics are handled automatically, there is little-to-no metaprogramming, and most of the API is just simple convenience combinators with obvious implementations: https://github.com/rust-lang/rust/blob/master/library/core/src/option.rs#L518 https://github.com/rust-lang/rust/blob/master/library/core/s... If nothing else, this is a clear counterexample to the claim that "Option and Result types are as easily coded in C++."
- ncmncm 4y ago
  > it's just what it takes to do this in C++ False.
  - LegionMammal978 4y ago
    Do you have any examples of how std::optional could be implemented more simply?
    - ncmncm 4y ago
      The std::optional in MSVC was implemented in a language considerably behind current C++, for obvious reasons. The need to use template metaprogramming in implementations is much less, today.
      - LegionMammal978 4y ago
        How so? Some of the "enable_if"s can probably be replaced with "requires" syntax, as well as the "conjunction_v"s and "disjunction_v"s, but the majority of the complexity seems to be in expressing the various requirements imposed by the Standard. Are there recently-added concepts (or other features) that would express them more naturally?
- arinlen 4y ago
  > I mean, have you looked at them? Last time I looked at Rust's std::Result, it's implemented as a tagged union. Most of C++'s implementations of a Result data type are implemented as tagged unions as well. What's your point? > This isn't a criticism of the team behind this code, it's just what it takes to do this in C++. The only conceivable argument you can possibly make is argue that Rust might support tagged unions as language primitives, but that would be totally pointless as Result types are relevant for the interfaces and higher level abstraction they provide, not your personal opinion of how hard someone else had to work to implement them. I've developed Result and Either types in a few languages, including C++, and the only hard thing about C++ is doing the usual homework to handle lvalur/revalue/revalue well.

Rusky 4y ago

I mean, have you looked at them? C++'s standard library optional type is a tagged union implemented from scratch, with a dizzying array of template metaprogramming to meet the standard's requirements- see e.g. Microsoft's here: https://github.com/microsoft/STL/blob/main/stl/inc/optional#L214 https://github.com/microsoft/STL/blob/main/stl/inc/optional#.... This isn't a criticism of the team behind this code, it's just what it takes to do this in C++. Rust gets most of that functionality from the language instead, in a much cleaner way. Sum types are built in, value categories and move semantics are handled automatically, there is little-to-no metaprogramming, and most of the API is just simple convenience combinators with obvious implementations: https://github.com/rust-lang/rust/blob/master/library/core/src/option.rs#L518 https://github.com/rust-lang/rust/blob/master/library/core/s... If nothing else, this is a clear counterexample to the claim that "Option and Result types are as easily coded in C++."

ncmncm 4y ago
> it's just what it takes to do this in C++ False.
- LegionMammal978 4y ago
  Do you have any examples of how std::optional could be implemented more simply?
  - ncmncm 4y ago
    The std::optional in MSVC was implemented in a language considerably behind current C++, for obvious reasons. The need to use template metaprogramming in implementations is much less, today.
    - LegionMammal978 4y ago
      How so? Some of the "enable_if"s can probably be replaced with "requires" syntax, as well as the "conjunction_v"s and "disjunction_v"s, but the majority of the complexity seems to be in expressing the various requirements imposed by the Standard. Are there recently-added concepts (or other features) that would express them more naturally?
arinlen 4y ago
> I mean, have you looked at them? Last time I looked at Rust's std::Result, it's implemented as a tagged union. Most of C++'s implementations of a Result data type are implemented as tagged unions as well. What's your point? > This isn't a criticism of the team behind this code, it's just what it takes to do this in C++. The only conceivable argument you can possibly make is argue that Rust might support tagged unions as language primitives, but that would be totally pointless as Result types are relevant for the interfaces and higher level abstraction they provide, not your personal opinion of how hard someone else had to work to implement them. I've developed Result and Either types in a few languages, including C++, and the only hard thing about C++ is doing the usual homework to handle lvalur/revalue/revalue well.