Untyped nil means literal nil?

[Victor Giordano]

Hello guys, just wanna clarify if the words "Untyped nil" refers to the nil value placed literally within a expresion, instead of being placed "behind" a variable, a constanst or a function call return value. So basically, can i say (in a classroom) that untyped nil means literal nil?

Is that correct?

Thanks!

[Victor Giordano]

Just to add context, and please don't take it bad, is that the word "nil" (or null) refers to a value not to a type (in every other language i know and i teach), so if there is something i'm not seeing i guess this is right place to ask.

[Ian Lance Taylor]

On Thu, Dec 19, 2019 at 4:42 PM Victor Giordano <vituc...@gmail.com> wrote:
>
> Hello guys, just wanna clarify if the words "Untyped nil" refers to the nil value placed literally within a expresion, instead of being placed "behind" a variable, a constanst or a function call return value. So basically, can i say (in a classroom) that untyped nil means literal nil?
> Is that correct?

I wouldn't say that they are exactly the same. Go supports untyped
constants, as described at https://golang.org/blog/constants. The
predeclared identifier "nil" is similar to an untyped constant, except
that it doesn't have a default type. If you write "var a *byte = nil"
then the "nil" acquires the type "*byte" from context. But if you
write "var a = nil" then there is type in context. Since "nil"
doesn't have a default type, the case "var a = nil" is a use of an
untyped nil, which is an error.

So an untyped nil is the use of a literal nil when there is no type context.

Ian

[roger peppe]

It's probably also worth saying that this is a bit more fuzzy with nil than with other constants, because in some sense every nil interface value, although having a static type (the interface type) is untyped in the sense that it doesn't have a dynamic type.

This is a common source of confusion.

A few different kinds of nil:

- statically untyped nil, as described by Ian - this is a compile-time-only thing

- statically typed nil - any nil value at runtime.

- dynamically untyped nil - a value of interface type that isn't associated with an underlying dynamic type

- dynamically typed nil - a value of interface type with an underlying dynamic type that's nil.

Although technically incorrect, I think "untyped nil" is often used to refer to the third of those things.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXv8puXkY%2BC3R_GJG6ZcNo_%2BNJuv5bPhvsn0LGr_0Wpjg%40mail.gmail.com.

[Axel Wagner]

Personally, in a classroom context, I'd avoid the term "untyped nil" (or "typed nil", for that matter) for interface values - specifically *because* I find it confusing. That is, I would point out that it is sometimes used that way (so people don't get confused if they hear it), but insist on the parlance from the spec:

- An interface value can be nil, in which case it has no dynamic type/value

- An interface value can be non-nil, in which case its dynamic value might or might not be nil (depending on whether the dynamic type allows it)

https://golang.org/ref/spec#Variables

That is, instead of calling something a typed or untyped nil (neither of which is parlance defined by the language - "untyped nil" is an error message from the compiler, that might be more appropriately worded as "can't infer type of nil-identifier"), you talk about whether an interface value has a dynamic value and whether or not that dynamic value is nil.

I will never be able to remember what an untyped nil is supposed to be (that is, which of the cases it to denotes) and I will never understand why someone came up with that, if there is already an authoritatively and unambiguously defined term :)

PS: I know that Roger already mentioned that it's technically incorrect, I just wanted to make explicit what I think *is* correct and what I think ought to be taught instead. :)

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAJhgacjAHmbggMSotha3Yr0_O9ATv1V8GKdB65kkLCKGovwBqA%40mail.gmail.com.

[Victor Giordano]

Ok, first at all, thanks to all of you for the valuable feedback!!! 

So the "untyped"|"typed"<whatever> comes from the terminology that Go uses for defining constants, that, in turn, is based on how you write those constants. If you explicit the type is a typed if not, is untyped.

And, for the sake of explaning a little bit, without diving into deeper areas, if correct to say that somewhere in the very base source files of go you will find something like this?

 
// untyped constant (the untyped nil)

const nil = 0 (assuming that nil/null is the zero address)

And, in another world, where people also program in Go (would be awesome right? xD), you may find a definition like this...

// a typed constant (...and that would be a "typed nil")

const nil *byte = 0 

As Ian point out, i, guess the more proper thing to say, for the sake of simplicity,:

An untyped nil is the use of a literal nil when there is no type context.

Pepe and Alex, i' like how you name the interfaces based on how they "refer" to the nil value. Problably i will take some of that terminology!

Is worth to mention that i found this article https://golang.org/doc/faq#nil_error very interesting!