This is cool - I’ve been thinking about this asymmetry too.

I think it’s important to note that the tag is an important part of the enum. Product types have field names (structs) or indices (tuples), with each field containing a value. Sum types have tag names (e.g. MyEnum::Left in the blog post) where each tag might contain some value.

So to me the dual to an anonymous tuple would be a enum with tags 0, 1, etc that automatically derives traits based on the types it encapsulates. I’m not sure if the syntax of rust is ammenable to having integer tags quite like this - you could probably do an anonymous enum with identifiers for the tags though (the dual of an anonymous struct). But “tagless” unions like u8 | str seem completely different to what is in rust today, and adding them wouldn’t remove the asymmetry.

(I’ve been imagining a structurally-typed language with a subset of the grammar being a JSON-like literal syntax for both structs and enums with some kind of “dual” syntax between them. E.g. you construct a struct like x = { a: 1, b: 2 }, then destructure it with x.a. You’d construct a dual type by reversing the getfield notation, so I’m thinking y = .a 1, and you’d destructure this with a switch statement like switch y { a: 10, b: 20 } or similar. You could maybe manage something similar with nominal typing. Perhaps in rust for anonymous enums you have no name for MyEnum so a value is just constructed like ::Left(1). To make it nice to use it’s the compiler’s job to “union” the enum types automatically during type inference, say if two branches return two different, but compatible, anonymous enum values).