> For clarity, it might make sense to amend the definition-looking section of > the spec with a blurb in the spirit of "defined types are those arising from > a type definition, or the predeclared types yadayadayada" (where yadayadayada > could be a list, could be the empty string if we resolve the error ambiguity > or could be "except error"). That way, if someone uses a "defined type" link > to see what it means (as Christoph did here for assignability) they'll get an > immediate answer about the implications.
This. I agree it is all somewhere in the spec if I search long enough, but having the important parts in one place would definitely be an enormous time saver. Thanks Axel for your input. On 8. May 2020, 17:42 +0200, Axel Wagner <axel.wagner...@googlemail.com>, wrote: > https://golang.org/ref/spec#Type_definitions > > A type definition creates a new, distinct type with the same underlying > > type and operations as the given type, and binds an identifier to it. […] > > The new type is called a defined type. It is different from any other type, > > including the type it is created from. > > This seems to imply, when taking as the sole definition of the word "defined > type", that predeclared identifiers are in fact *not* defined types, as they > don't originate from a type definition. I agree with Christoph here - if you > follow any "defined type" link to this definition, which is formatted as a > definition (italics are a classical typographical hint to denote a term being > defined), that definition prevents any of the predeclared types from being > considered "defined types". > > However: > > https://golang.org/ref/spec#Boolean_types > > […] The predeclared boolean type is bool; it is a defined type. > https://golang.org/ref/spec#Numeric_types > > […] To avoid portability issues all numeric types are defined types […] > https://golang.org/ref/spec#String_types > > […] The predeclared string type is string; it is a defined type. […] > https://golang.org/ref/spec#Errors > …hmmmmmmmm. I assume it doesn't make a difference here, as it's an interface > type, so other parts of the spec apply wherever it's important. I'll play > around for a bit :) > > So, while the actual definition *is* ambiguous, the spec as a whole is not - > it very clearly states that the predeclared types are defined types. > Note, that the section "predeclared identifiers" itself is not important here > - being declared and being defined are different words and `errors` is > predeclared, but, apparently, not defined. Language lawyering this way is > annoying, but it's also what writing a spec is all about. "defined" and > "declared" are similar, but distinct terms. > > For clarity, it might make sense to amend the definition-looking section of > the spec with a blurb in the spirit of "defined types are those arising from > a type definition, or the predeclared types yadayadayada" (where yadayadayada > could be a list, could be the empty string if we resolve the error ambiguity > or could be "except error"). That way, if someone uses a "defined type" link > to see what it means (as Christoph did here for assignability) they'll get an > immediate answer about the implications. > > > On Fri, May 8, 2020 at 4:43 PM Jan Mercl <0xj...@gmail.com> wrote: > > > On Fri, May 8, 2020 at 4:31 PM Christoph Berger > > > <christophberger....@gmail.com> wrote: > > > > > > > Unfortunately, the connection between "predeclared" (or "implicitly > > > > declared" as the first paragraph says) and "defined" is not at all > > > > obvious. Especially as the definition of "defined type" refers to types > > > > explicitly declared via the "type" keyword. > > > > > > The definition of "defined type" is correct and simple, no special > > > rules exists. The predeclared identifier `int` is declared that way, > > > except it's done by the compiler without the need to do it in user > > > code. See here: https://godoc.org/builtin#int > > > > > > Of course, the builtin package is only a formal definiton, it has > > > special treatment by the compiler, so doing the same in user code > > > would be invalid. Still `int` is defined and treated as `type int > > > something` and it's thus a defined(named) type. > > > > > > In the first approximation, any type represented by a name is a > > > defined type. Later came type aliases, so now it's a bit more > > > complicated b/c one can write also `type T = []U` where T is not a > > > defined type b/c []U is not a defined type. > > > > > > -- > > > 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/CAA40n-WzJAWpg4TEcW%2BZ2G-1zcUFNiSS0ezJtz6077Z4U3uwUQ%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/66c0cfb3-d1a2-417a-94a5-04aca48e1fbc%40Spark.
