4 ms·

A few code snippets of what you see as weaknesses of std::variant may be appropriate, as I couldn't figure out your complaint. Assigning to a variant taken by n

• amluto 2y ago
  I think the comment means: std::variant<int&, etc> does not work well.
  • nly 2y ago
    Just use std::variant<int*, ...> References in C++ are just sugary pointers.
    • robmccoll 2y ago
      References have one important property over pointers. They cannot be null.
      • tstack 2y ago
        They most certainly can be null as can “this”.
        • usefulcat 2y ago
          Only after dereferencing a null pointer, which would be the actual problem, not the fact that some reference or this is null.
        • Matheus28 2y ago
          You cannot have a null reference unless you invoke undefined behavior first.
      • cma 2y ago
        const ref lifetime extension is important to, or operator overloading wouldn't be workable.
      • gpderetta 2y ago
        Reference_wrapper then.
      • LowLevelMahn 2y ago
        they easily can :) void test(int& y){} int main() { int* x = nullptr; test(*x); }
        • josefx 2y ago
          There is a difference between an API promissing that a value wont be null and a buggy program setting a null where it should not. A reference is only null if someone fucked up. As a programmer you can usually rely on a reference not being null and you couldn't do anything about it if it was anyway within the constraints of the language.
          • TeMPOraL 2y ago
            In the same way, an `enum class` variable's value being outside of the set defined in the `enum class` is also a fuckup.
            • gpderetta 2y ago
              no, deferencing a null ptr is UB. An enum class outside the declared values is perfectly valid. You could design a language feature where integer to enum is checked, but that's not enum. Enum classes already add scoping, forbid implicit conversions and allow explicit underlying types. Those are pure extensions. Making undeclared values invalid or UB would be very surprising to people used to normal enums.
        • account42 2y ago
          And you can also open /proc/self/mem in a Rust program and overwrite whatever you want, including pointers. So?
          • Thiez 2y ago
            One of those cases happens accidentally all the time (in more complex variants than the motivating example you responded to), the other never happens except on purpose. It's like complaining guard rails are pointless because people being launched with catapults might still fly over them and plunge to their deaths.
• tlhand 2y ago
  std::variant is not a true algebraic data type, since the individual element constructors do not construct the variant type automatically. Compare to OCaml, written in a verbose and unidiomatic way that is similar to C++: # type foo = Int of { n : int } | Float of { f : float };; type foo = Int of { n : int; } | Float of { f : float; } # Int { n = 10 };; - : foo = Int {n = 10} # let r = ref (Int { n = 10 });; val r : foo ref = {contents = Int {n = 10}} Notice that the constructor Int { n = 10 } automatically produces a foo type and assigning to a mutable ref works. The same in C++, using assignment to a pointer to avoid the lvalue ref error that is irrelevant to this discussion: #include <variant> struct myint { int n; myint(int n) : n(n) {} }; struct myfloat { float f; myfloat(float f) : f(f) {} }; using foo = std::variant<myint, myfloat>; int main() { const foo& x = myint{10}; // works foo *z = new myint{10}; // error: cannot convert ‘myint*’ to ‘foo* } As stated above, this obviously cannot work since C++ has no way of specifying a myint constructor that -- like in OCaml -- automatically produces the variant type foo. C++ would need true algebraic data types with compiler support (that would hopefully be as fast as switch statements). To be useful, they would need a nice syntax and not some hypothetical abomination like: using foo = std::variant<myint, myfloat> where struct myint of foo { ... };