3 ms·
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:
by 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 agoI 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 agoIt'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.