News for hackers. Stuff that matters.
Re:Union types ('enum types') would be complicated in Go by brundolf on Saturday December 07, 2024 @02:55AM (#42348055)
Forget Result, just allow the type system to express non-nullable object references. Use the same layout, just let the compiler know when something is guaranteed to exist and force null-checking when it isn't

This doesn't cover everything people might want to do with unions, but it covers the billion-dollar mistake and doesn't run against the grain of the entire language (as far as I know)

Re:Union types ('enum types') would be complicated in Go by mrgriffin on Saturday December 07, 2024 @04:00AM (#42348345)
> doesn't run against the grain of the entire language

Not an expert, but my gut says maybe it runs against zero values? As in, "what's the zero value for a non-nullable reference?" Maybe the answer is something like "you can only use this type for parameters", but that seems very limiting.

Re:Union types ('enum types') would be complicated in Go by rudiksz on Saturday December 07, 2024 @05:15AM (#42348688)
Half of the language is already non-nullable and is accomplished by allowing for zero values. Non pointer variables are guaranteed to be never nil.

What is missing is the ability to have pointer variables and have the compiler ensure that it will be never nil. I believe this was a design choice, not some technical limitation.

Re:Union types ('enum types') would be complicated in Go by keybored on Saturday December 07, 2024 @07:45AM (#42349419)
Like the sibling comment seems to be saying: a non-nil pointer would have to be set to some real (non-nil) pointer value anyway. So having a zero value does not seem to apply?
Re:Union types ('enum types') would be complicated in Go by hellcow on Saturday December 07, 2024 @11:06AM (#42350626)
I've been using `Null[T any] struct { V T, Valid bool }` for this, as the pattern comes from database/sql. Works fine.