Should unions in JS be untagged?

[Liamolucko]

Types like string | URL are pretty common in JS, so would it be a good idea for unions to map to that rather than being the same as variants?

Implementing this could be quite tricky. When passing a type like that back to another module, the variant would have to be figured out based on the value. Some types would be impossible to distinguish from one another in JS, e.g. a union of u8 and u16. That would either have to be disallowed (probably a bad idea), or fall back on the default variant representation. The latter would be kind of weird and magical, though.

So, I'm not really sure if this is actually a good idea, but I thought I'd bring it up.

[alexcrichton]

I don't think that the current JS representation of variants is really all that great, and I think it'd be great to improve! I would ideally like to implement a representation trick where for:

variant url-like {
    literal(string),
    parsed(url),
}

struct url {
    // ... 
}

for that to be represented in JS as type UrlLike = string | URL. I believe we can do this because the url-like type has variants, each with a payload, each with a distinct JS class representing them, so cases can be determined by the class rather than using a discriminant. I think we'll still have to fall back to a discriminant for some cases, but I would hope that lots of cases could use a discriminant-less representation and delegate to type-checks for "checking the discriminant"

[esoterra]

I think what @Liamolucko might be suggesting is that variants be tagged, but unions be untagged in their JS representation, which is what I would personally vote for.