undefined | Better HN

0 pointsmcronce2y ago0 comments

With generics, can you not make a NonNil<T> struct in Go, where the contents of the struct are only a *T that has been checked at construction time to not be nil, and doesn't expose its inner pointer mutably to the public? I would think that would get the job done, but I also haven't really done much Go since prior to generics being introduced

Otherwise, since pointers are frequently used to represent optional parameters, generics + sum types would get the job done; for that use case, it's one of two steps to solve the problem. I don't foresee Go adding sum types, though.

0 comments

suremarc2y ago

Every type in Go has a zero value. The zero value for pointers is nil. So you can't do it with regular pointers, because users can always create an instance of the zero value.

tialaramex2y ago

This is one of those things which feels like just a small trade off against convenience for the language design, but then in practice it's a big headache you're stuck with in real systems.

It's basically mandating Rust's Default trait or the C++ default (no argument) constructor. In some places you can live with a Default but you wish there wasn't one. Default Gender = Male is... not great, but we can live with it, some natural languages work like this, and there are problems but they're not insurmountable. Default Date of Birth is... 1 January 1970 ? 1 January 1900? 0AD ? Also not a good idea but if you insist.

But in other places there just is no sane Default. So you're forced to create a dummy state, recapitulating the NULL problem but for a brand new type. Default file descriptor? No. OK, here's a "file descriptor" that's in a permanent error state, is that OK? All of my code will need to special case this, what a disaster.

codetrotter2y ago

> Default Gender = Male is... not great

    enum Gender {
        Unspecified,
        Male,
        Female,
        Other,
    }

    impl Default for Gender {
        default() -> Self {
            Self::Unspecified
        }
    }

or:

    enum Gender {
        Male,
        Female,
        Other,
    }

and use Option<Gender> instead of Gender directly, with Option::None here meaning the same that we would mean by Gender::Unspecified

1 more reply

andreyvit2y ago

Default gender male not how this works in practice. Instead, you define an extra “invalid” value for almost every scalar type, so invalid would be 0, male 1 and female 2. Effectively this makes (almost) every scalar type nullable. It is surprisingly useful, though, and I definitely appreciate this tradeoff most of the time.

(Sometimes your domain type really does have a suitable natural default value, and you just make that the zero value.)

1 more reply

tptacek2y ago

This is a thread about Go, not about Rust. There is a bunch of interesting computer science in this post, and if interesting new computer science is a baby seal, Rust vs. Go discussions are hungry orcas.

maccard2y ago

I write a decent amount of go - this isn't a defence of the current situation.

> All of my code will need to special case this, what a disaster.

No, your code should handle the error state first and treat the value as invalid up until that point, e.g.

    foo, err := getVal()
    if err != nil {
        return
    }

    // foo can only be used now

It's infuriating that there's no compiler support to make this easier, but c'est la vie.

1 more reply

jasonhansel2y ago

One answer would be to provide something like a GetPointer() method which, if the inner pointer is nil, creates a new struct of type T and returns a pointer to it.

stouset2y ago

Turns out worse isn’t better after all. Who could have guessed?

Mawr2y ago

You can make such a type and it works well in practice.

First we define the type, hiding the pointer/non-existent value:

    type Optional[Value any] struct {
        value  Value
        exists bool
    }

Then we expose it through a method:

    func (o Optional[Value]) Get() (Value, bool) {
        return o.value, o.exists
    }

Accessing the value then has to look like this:

    if value, ok := optional.Get(); ok {
        // value is valid
    }
    // value is invalid

This forces us to handle the nil/optional code path.

Here's a full implementation I wrote a while back: https://gist.github.com/MawrBF2/0a60da26f66b82ee87b98b03336e...

tw0610232y ago

Even if this would be possible, it won't be idiomatic.

j / k navigate · click thread line to collapse

0 comments

suremarc2y ago

Every type in Go has a zero value. The zero value for pointers is nil. So you can't do it with regular pointers, because users can always create an instance of the zero value.

tialaramex2y ago

This is one of those things which feels like just a small trade off against convenience for the language design, but then in practice it's a big headache you're stuck with in real systems.

codetrotter2y ago

> Default Gender = Male is... not great

    enum Gender {
        Unspecified,
        Male,
        Female,
        Other,
    }

    impl Default for Gender {
        default() -> Self {
            Self::Unspecified
        }
    }

or:

    enum Gender {
        Male,
        Female,
        Other,
    }

and use Option<Gender> instead of Gender directly, with Option::None here meaning the same that we would mean by Gender::Unspecified

1 more reply

andreyvit2y ago

(Sometimes your domain type really does have a suitable natural default value, and you just make that the zero value.)

1 more reply

tptacek2y ago

maccard2y ago

I write a decent amount of go - this isn't a defence of the current situation.

> All of my code will need to special case this, what a disaster.

No, your code should handle the error state first and treat the value as invalid up until that point, e.g.

    foo, err := getVal()
    if err != nil {
        return
    }

    // foo can only be used now

It's infuriating that there's no compiler support to make this easier, but c'est la vie.

1 more reply

jasonhansel2y ago

One answer would be to provide something like a GetPointer() method which, if the inner pointer is nil, creates a new struct of type T and returns a pointer to it.

stouset2y ago

Turns out worse isn’t better after all. Who could have guessed?

Mawr2y ago

You can make such a type and it works well in practice.

First we define the type, hiding the pointer/non-existent value:

    type Optional[Value any] struct {
        value  Value
        exists bool
    }

Then we expose it through a method:

    func (o Optional[Value]) Get() (Value, bool) {
        return o.value, o.exists
    }

Accessing the value then has to look like this:

    if value, ok := optional.Get(); ok {
        // value is valid
    }
    // value is invalid

This forces us to handle the nil/optional code path.

Here's a full implementation I wrote a while back: https://gist.github.com/MawrBF2/0a60da26f66b82ee87b98b03336e...

tw0610232y ago

Even if this would be possible, it won't be idiomatic.

j / k navigate · click thread line to collapse