You can obviously only call common methods or have to pattern match later and have a way to tell them apart. If you can't tell them apart, the compiler will tell you and you need to tag them somehow.
That sounds like trait objects/dynamic dispatch/`dyn`, which comes with runtime costs.
> or have to pattern match later and have a way to tell them apart.
That "way to tell them apart" is a tag, which would make it a tagged union/enum, not an untagged union. Those already exist, though not in an anonymous flavour.
It does, but the developer decides. Also, errors are often propagated and only matched in exceptional cases, so I don't think the impact would be big.
> That "way to tell them apart" is a tag, which would make it a tagged union/enum, not an untagged union.
No. The difference is that a tagged union (sum type) is defined in advance but generally a union is not necessarily tagged but _can_ be tagged.
Example: say you have tagged union with 3 different types / tags A, B and C.
You can now define an adhoc/untagged union that is A | C. That means, we can guarantee at compile time, that we will be able to tell A and C apart later. But it is still not the same, because the combination of A and C was decided adhoc and was not predefined by the developer anywhere necessarily - which is what makes it different from A, B, C which where specifically defined by the developer.
That sounds like trait objects/dynamic dispatch/`dyn`, which comes with runtime costs.
> or have to pattern match later and have a way to tell them apart.
That "way to tell them apart" is a tag, which would make it a tagged union/enum, not an untagged union. Those already exist, though not in an anonymous flavour.