... yes? One still needs to put it in sum types sometimes. This is what std::variant solves.

But that is the point; "union" is supposed to be a POD, if not all language guarantees are off.

> But that is the point; "union" is supposed to be a POD

no it's not. it's fine to have non-POD unions - but you have to be careful to call constructors and destructs of non-POD's explicitly. thus, variant which automates that.

Also, I didn't talk specifically about unions, but about sum types. There is a need for saying that an object X can be of type A OR type B, no matter the properties of these types.

>it's fine to have non-POD unions

Only from C++11 (or is it later?). So a problem was created by relaxing the existing requirements for a "union" to which a solution was proposed by adding a "variant"? Something which had no runtime overhead (but UB) now has runtime overheads.

Regarding your point about "sum types", agreed.