Union types and enum types are not the same thing, and this misunderstanding invalidates the entire article. An enum type includes a marker which indicates which value it contains. The garbage collector would be able to read this tag value and know.
What Rust calls enums are called tagged unions in most other languages. Enum usually refers to a simple collection of named values, what Rust calls fieldless enums or unit-only enums.
Not sure about that. Swift also calls them enums, in Java and Kotlin (and maybe Scala? I forget) they're sealed classes/interfaces and in PL theory and many typed FP languages they're called "sum types".
Enumerations are a sequence of values.
To put it another way, a Rust `enum` is not the same as C's untagged unions but it is still a union.
> let's ask why we can't implement such a union type today using Go's unsafe package to perform suitable manipulation of a suitable memory region.
They are aware that you could add union types to Go - their point is that it would require garbage collector modifications which may be difficult:
> The corollary to all of this is that adding union types to Go as a language feature wouldn't be merely a modest change in the compiler. It would also require a bunch of work in how such types interact with garbage collection, Go's memory allocation systems (which in the normal Go toolchain allocate things with pointers into separate memory arenas than things without them), and likely other places in the runtime.
In the sense that it first points to the type, and then to the value, similar to how other newer types are already implemented?
type whatever enum {
value1 iota
value2
enum would just be a similar shorthand to uint or whatever you want to identify it uniquely.
I don't see much problem implementing this apart from the methods in the GC that have to be touched to trace the object tree correctly.
The comparison handling must be touched in either case, so I don't think an additional pointer to the enum's definition there counts as much work.