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

21–30 of 119 posts

Re: Typed nils in Go 2

#21

Post by marcus_holmes »

abtinf wrote: post #8
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`.

Can't that be determined by looking at the row count? A row count of zero means it doesn't exist. A row count of 1 with a null in the selected column means the row exists the column is null. I avoid the word "empty" when referring to anything SQL related, as it is ambiguous in three value logic.

I think they're referring to outer-joined tables.

SELECT a.id, b.name FROM a LEFT JOIN b ON a.id = b.id

If you get a NULL in the name field, you don't know if that's because there's no record in b for that id, or if there is a record in b for that id but it has a NULL name value. Sometimes that difference will be important.

Re: Typed nils in Go 2

#22

Post by gondo »

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.

"the type of an interface is nil" is that even possible?

Re: Typed nils in Go 2

#23

Post by tonyedgecombe »

tjholowaychuk wrote: post #14
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`?

You can fix that with exceptions :)

Re: Typed nils in Go 2

#25

Post by mjevans »

biztos wrote: post #16
maerF0x0 wrote: post #11

Earlier quoted context omitted.

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.

Or worse having to inspect a specific field value (or worse compare the whole thing to a reference object) to determine if the result is actually valid or not.

The question I ask in these circumstances: Will a method/function //always// return valid work if the program continues to run?

How about a 'find' function of some type? Find the nth thing, find matches of X, etc.

That's one type of function that might return no answer.

If a list or set of some sort is expected I'm happy with a zero-length list in this case. However lists aren't the only time this happens. The most recent example to come to my mind is finding the Nth item in an arbitrary sequence. That item might be out of bounds (not exist). Nil is appropriate for that case.

Re: Typed nils in Go 2

#26

Post by _pmf_ »

hoodoof wrote: post #20

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.

"Go should stay simple, it does not need generics."

Re: Typed nils in Go 2

#27

Post by mbertschler »

gondo wrote: post #22
dullgiulio wrote: post #3

Earlier quoted context omitted.

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.

"the type of an interface is nil" is that even possible?

Yes it is. An interface is basically a struct of the concrete type and the value. While the outer interface value still has a type, if no value was assigned to it, the concrete type field is still nil.

Re: Typed nils in Go 2

#28

Post by p4lindromica »

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.

this is called a bottom type in a type system. In JVM languages null and the throw expression return the bottom type.

The only other option is to not have nil values.

Re: Typed nils in Go 2

#29

Post by TheDong »

tjholowaychuk wrote: post #14
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`?

Allow an Either monad via allowing sum types, solved.

Once you have an either type, you can also get rid of nil entirely since a Maybe type is trivially created with an Either.

Designing languages without a null value (other than for c-interop via e.g. `C.null`) is a solved problem.

Re: Typed nils in Go 2

#30

Post by TheDong »

gondo wrote: post #22
dullgiulio wrote: post #3

Earlier quoted context omitted.

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.

"the type of an interface is nil" is that even possible?

That, in fact, is the normal case which is why people are surprised by typed nils.

For example:

    func returnsNil() error { return nil }

    x := returnsNil()
    // x is of type nil and value nil.
Post reply on HN