4 ms·

In principle, nothing stops C++ compilers from implementing this feature. However, this - requires additional input from the programmer, such as lifetime para

by m1el 10y ago

In principle, nothing stops C++ compilers from implementing this feature. However, this - requires additional input from the programmer, such as lifetime parameters in Rust. - C and C++ don't have ADTs which help working with lifetimes A LOT (e.g. having Option<Box<T>> as nullable pointer). - will reject 99.9% of useful libraries and programs written in C. - would be equivalent to using Rust.

lmm 10y ago
For the record C++17 does introduce std::variant. It's horribly cumbersome but it does at least exist.
- m1el 10y ago
  It's horribly cumbersome AND it doesn't solve the same problem. // Rust let v: Result<i32, i32> = Ok(1); // std::variant (doesn't compile) std::variant<i32, i32> v = 1;
  - wyldfire 10y ago
    I had to RTFM a bit to understand this example, so here's a more explicit description of this case for those playing along at home: AFAICT the idiom for Result<i32, i32> is a pair of "numerical-result-if-success"/"errno-if-failure". Seems like a great idea, allows us to not overload a simple integer result and end up ignoring the failure path by accident. "Ok(n)" would get assigned to the "numerical-result-if-success" and "Err(m)" would get assigned to the "errno-if-failure". I think this means that "v.unwrap()" would panic if it had been assigned "Err(m)", which is what most people would want/expect. AFAICT std::variant can't do overload resolution correctly when both of the union types are the same. I'll wager that if you use an aliased type it will still choke on this ambiguity. So if you wanted something similar in C++ maybe you'd have to wrap it so it's not POD?
    - m1el 10y ago
      It's not quite a "pair". It's a "tagged union" in C-speak, "enum" in Rust-speak and "sum type" in CS-speak. In this case, numerical result and errno will be located in the same memory, but have different tag.

by m1el 10y ago

lmm 10y ago

For the record C++17 does introduce std::variant. It's horribly cumbersome but it does at least exist.

m1el 10y ago
It's horribly cumbersome AND it doesn't solve the same problem. // Rust let v: Result<i32, i32> = Ok(1); // std::variant (doesn't compile) std::variant<i32, i32> v = 1;
- wyldfire 10y ago
  I had to RTFM a bit to understand this example, so here's a more explicit description of this case for those playing along at home: AFAICT the idiom for Result<i32, i32> is a pair of "numerical-result-if-success"/"errno-if-failure". Seems like a great idea, allows us to not overload a simple integer result and end up ignoring the failure path by accident. "Ok(n)" would get assigned to the "numerical-result-if-success" and "Err(m)" would get assigned to the "errno-if-failure". I think this means that "v.unwrap()" would panic if it had been assigned "Err(m)", which is what most people would want/expect. AFAICT std::variant can't do overload resolution correctly when both of the union types are the same. I'll wager that if you use an aliased type it will still choke on this ambiguity. So if you wanted something similar in C++ maybe you'd have to wrap it so it's not POD?
  - m1el 10y ago
    It's not quite a "pair". It's a "tagged union" in C-speak, "enum" in Rust-speak and "sum type" in CS-speak. In this case, numerical result and errno will be located in the same memory, but have different tag.