6 ms·

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 ni

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.

tw061023 3y ago
Even if this would be possible, it won't be idiomatic.
suremarc 3y 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.
- tialaramex 3y 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.
  - maccard 3y 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.
    - leftyspook 3y ago
      Man, if only over 30 odd years of PL research leading up to Go, somebody came up with a way to do it better.
      - pstuart 3y ago
        And yet it's a productive language with significant adoption, go figure. They made trade-offs and are conservative about refining the language; that cuts both ways but works well for a lot of people. The Go team does seem to care about improving it and for many that use it, it keeps getting better. Perhaps it doesn't happen at the pace people want but they always have other options.
        stouset 3y ago
        > And yet it's a productive language with significant adoption, go figure. Perl was also a successful language with significant adoption. At least back then, we didn’t know any better. In twenty years the industry will look back on golang as an avoidable mistake that hampered software development from maturing into an actual engineering discipline, for the false economy of making novice programmers quickly productive. I’m willing to put money on that belief, given sufficiently agreed upon definitions.
        pstuart 3y ago
        Perl had less competition and also suffered from being more of a "write-only" language. Lisp, Haskell, OCaml all likely tickle your PL purity needs, but they remain niche languages in the grand scheme of things. Does that make them bad? I think Go will be the new Java (hopefully without the boilerplate/bloat). It's good enough to do the job in a lot of cases and plenty of problems will be solved with it in a satisfactory manner. Language wars are only fun to engage with for sport, but it's silly to get upset about them. Most languages have value in different contexts and I believe the real value in this dialog is recognizing when and where a language works and to accept one's preferred choice may not always be "the one".
- jasonhansel 3y 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.
- stouset 3y ago
  Turns out worse isn’t better after all. Who could have guessed?
Mawr 3y 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/0a60da26f66b82ee87b98b03336e1f84 https://gist.github.com/MawrBF2/0a60da26f66b82ee87b98b03336e...

tw061023 3y ago

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

suremarc 3y 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.

tialaramex 3y 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.
- maccard 3y 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.
  - leftyspook 3y ago
    Man, if only over 30 odd years of PL research leading up to Go, somebody came up with a way to do it better.
    - pstuart 3y ago
      And yet it's a productive language with significant adoption, go figure. They made trade-offs and are conservative about refining the language; that cuts both ways but works well for a lot of people. The Go team does seem to care about improving it and for many that use it, it keeps getting better. Perhaps it doesn't happen at the pace people want but they always have other options.
      - stouset 3y ago
        > And yet it's a productive language with significant adoption, go figure. Perl was also a successful language with significant adoption. At least back then, we didn’t know any better. In twenty years the industry will look back on golang as an avoidable mistake that hampered software development from maturing into an actual engineering discipline, for the false economy of making novice programmers quickly productive. I’m willing to put money on that belief, given sufficiently agreed upon definitions.
        pstuart 3y ago
        Perl had less competition and also suffered from being more of a "write-only" language. Lisp, Haskell, OCaml all likely tickle your PL purity needs, but they remain niche languages in the grand scheme of things. Does that make them bad? I think Go will be the new Java (hopefully without the boilerplate/bloat). It's good enough to do the job in a lot of cases and plenty of problems will be solved with it in a satisfactory manner. Language wars are only fun to engage with for sport, but it's silly to get upset about them. Most languages have value in different contexts and I believe the real value in this dialog is recognizing when and where a language works and to accept one's preferred choice may not always be "the one".
jasonhansel 3y 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.
stouset 3y ago
Turns out worse isn’t better after all. Who could have guessed?

Mawr 3y 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/0a60da26f66b82ee87b98b03336e1f84 https://gist.github.com/MawrBF2/0a60da26f66b82ee87b98b03336e...