Re:Union types ('enum types') would be complicated in Go
by foldr on Thursday December 05, 2024 @04:21AM
(#42326442)
I was saying that you can have a single allocation without using bit packing.
I'm not sure what you're referring to with 'anything more ambitious'.
Re:Union types ('enum types') would be complicated in Go
by treyd on Friday December 06, 2024 @10:25PM
(#42346996)
> The problem with allocating bit-packed storage is that then you are into the issue where types don't agree on where any pointers are.
The solution to this should be trivial. You just have to extend the gcshape concept to account for the enum discriminator.
Re:Union types ('enum types') would be complicated in Go
by ryanpetrich on Friday December 06, 2024 @10:57PM
(#42347144)
The bigger problem is mutability. Any pointers into the bit-packed enum storage become invalid as soon as you change its type. To solve this you can either prohibit pointers into bit-packed enum storage, which is very limiting, or introduce immutability into the language. Immutability is particularly difficult to add to go, where default zero-values emerge in unexpected places (such as the spare capacity of slices and the default state of named return values)
I agree with you about the overall motivation for Rust-style enums. I just think it's surprisingly complex to get even the memory efficiency advantages, never mind anything more ambitious.