Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Typed nils in Go 2

dave.cheney.net

Post reply on HN
Print view View original

11–20 of 119 posts

Re: Typed nils in Go 2

#11

Post by maerF0x0 »

mjevans wrote: post #9
clusmore wrote: post #7

Earlier quoted context omitted.

My problem with null is that it doesn't nest. For example, if I do a DB search for a particular column of a particular row and get null, does that mean the row doesn't exist, or it does but the column is empty? With optionals, you can distinguished between this with e.g. `Nothing` vs `Just Nothing`.

In databases NULL does exist; it is an explicit statement of having no contained value. (There is a container here, the contents were not specified. A distinct statement from /knowing/ the contents to be empty. (zero, zero-length string, etc)) Conceptually NULL or nil is an appropriate concept for results that have no meaning, such as if an error occurred or if a passed value is not required or valid. (Though some st…

kind of like having

field_is_set = true, field = "123"

field_is_set = false, field = 0 (some zero value or uninitialized value)

Re: Typed nils in Go 2

#12

Post by nerdponx »

taeric wrote: post #5
inopinatus wrote: post #4

The more experienced a developer I become, the more strongly (and negatively) I feel about nils and nulls and their ilk. I have sympathy for C.A.R.Hoare who in 2009 apologised for the apparent invention of null references in ALGOL W (1965), calling them a "billion-dollar mistake". I've come to regard them as a data singularity, and when I design data structures and interfaces today I am deliberately avoiding/outlawin…

Funny, I'm the opposite. The more experienced I've become, the more I've found that nil-punning is ultimately what I actually wanted. And I'm all for the idea that relational fields should be NOT NULL. I also fear that this doesn't really work for backwards compatible thinking. If I serialized some data down to disk before a field existed, I don't expect it to be there when I check it later. You can be tempted to thi…

I'm all for the idea that relational fields should be NOT NULL

What if the data is actually missing? How else do you record that information?

Re: Typed nils in Go 2

#13

Post by maerF0x0 »

IMO the language made a mistake by allowing nil to satisfy any interface . When I write a function like

   func DoStuf(i ILoveGoer) { 
     i.LoveGo() // Panic on nil
   }
its hard to reason about because it doesnt look like you have a pointer, looks like you definitely have a value. IMO a nil should not be allowed for an interface. So the only way to create an interface var is in conjunction with assignment.

Re: Typed nils in Go 2

#14

Post by tjholowaychuk »

maerF0x0 wrote: post #13

IMO the language made a mistake by allowing nil to satisfy any interface . When I write a function like func DoStuf(i ILoveGoer) { i.LoveGo() // Panic on nil } its hard to reason about because it doesnt look like you have a pointer, looks like you definitely have a value. IMO a nil should not be allowed for an interface. So the only way to create an interface var is in conjunction with assignment.

what about `error`?

Re: Typed nils in Go 2

#15

Post by zupa-hu »

nerdponx wrote: post #12
taeric wrote: post #5

Earlier quoted context omitted.

Funny, I'm the opposite. The more experienced I've become, the more I've found that nil-punning is ultimately what I actually wanted. And I'm all for the idea that relational fields should be NOT NULL. I also fear that this doesn't really work for backwards compatible thinking. If I serialized some data down to disk before a field existed, I don't expect it to be there when I check it later. You can be tempted to thi…

I'm all for the idea that relational fields should be NOT NULL What if the data is actually missing? How else do you record that information?

You use the default empty value, and have an extra field for missingness. Than you have real type safety.

Re: Typed nils in Go 2

#16

Post by biztos »

maerF0x0 wrote: post #11
mjevans wrote: post #9

Earlier quoted context omitted.

In databases NULL does exist; it is an explicit statement of having no contained value. (There is a container here, the contents were not specified. A distinct statement from /knowing/ the contents to be empty. (zero, zero-length string, etc)) Conceptually NULL or nil is an appropriate concept for results that have no meaning, such as if an error occurred or if a passed value is not required or valid. (Though some st…

kind of like having field_is_set = true, field = "123" field_is_set = false, field = 0 (some zero value or uninitialized value)

Sort of... and it seems to me that Go wants you to think this way about values within a struct (i.e. the "zero" values).

But isn't that a really clunky way of checking whether field is set? You can't just check field because the "zero value" could be a legit value, e.g. zero. So you have to first check field_is_set -- and now you have to make sure that's always correct and that nobody ever sets field by itself.

Re: Typed nils in Go 2

#17

Post by tjholowaychuk »

inopinatus wrote: post #4

The more experienced a developer I become, the more strongly (and negatively) I feel about nils and nulls and their ilk. I have sympathy for C.A.R.Hoare who in 2009 apologised for the apparent invention of null references in ALGOL W (1965), calling them a "billion-dollar mistake". I've come to regard them as a data singularity, and when I design data structures and interfaces today I am deliberately avoiding/outlawin…

NOT NULL bugs me too, but not so much because nulls are possible, more so that I think it should be inverted since that's the common case (at least for me).

Re: Typed nils in Go 2

#18

Post by pyrale »

Gotta love how the initial problem (a typed language in the 2000s having nil and empty interfaces) degenerates in workaround suggestions such as hacking nil and the interface system to give it a special type.

Re: Typed nils in Go 2

#19

Post by [deleted] »

dullgiulio wrote: post #3
nie wrote: post #2

I enjoyed the blog article and I would like to gently reiterate the notion that a _typed nil_ in Go 2 would change the semantic of _nil_, as seen in the example expression at the end of the article: var b *bytes.Buffer var r io.Reader = b fmt.Println(r == nil) We might need to use other expressions to capture the _nil_ type of above assignment but we should enable the _value only_ equality check with `r == nil`

Can someone point me to some examples where checking that the type of an interface is nil? I have thought a bit about it but I couldn't come up with good situations.

[deleted]

Re: Typed nils in Go 2

#20

Post by hoodoof »

This may be the "computing industry sentence of the year", if they had an award for "sentence of the year", which I'm sure they don't. Whoever they are.

while nil is assigned to t2, when t2 is passed to factory it is “boxed” into an variable of type P; an interface. Thus, thing.P does not equal nil because while the value of P was nil, its concrete type was *T.

Post reply on HN