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! El vie., 20 dic. 2019 a las 6:21, Axel Wagner (< axel.wagner...@googlemail.com>) escribió: > 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. :) > > On Fri, Dec 20, 2019 at 9:59 AM roger peppe <rogpe...@gmail.com> wrote: > >> 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. >> >> >> >> On Fri, 20 Dec 2019 at 06:53, Ian Lance Taylor <i...@golang.org> wrote: >> >>> On Thu, Dec 19, 2019 at 4:42 PM Victor Giordano <vitucho3...@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 >>> >>> -- >>> 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+unsubscr...@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 >>> . >>> >> -- >> 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+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAJhgacjAHmbggMSotha3Yr0_O9ATv1V8GKdB65kkLCKGovwBqA%40mail.gmail.com >> <https://groups.google.com/d/msgid/golang-nuts/CAJhgacjAHmbggMSotha3Yr0_O9ATv1V8GKdB65kkLCKGovwBqA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAPUu9suReTx0mkN2N3UbW1mFsNDjQykE%2BQZtHJogvATEd0wwMw%40mail.gmail.com.
