> This thread isn't "please help me understand how the language works",
it's "does the spec accurately and unambiguously define how the language
works".
Sure, I'm happy to stick to that.
Can you tell me if you agree that the spec is clear on this point: that if
I write
type MyError interface {
error() string
}
then MyError is a "defined type"? I think it is clear: this is
structurally a type definition, and the spec makes no distinction between
interface types and other types in this context.
If you agree with that, then the question hinges on whether the built-in
error interface being "predeclared" somehow emasculates its "defined type"
nature which it would otherwise have from the structure of its
(pre)declaration. I don't see anything that suggests it does.
If there is ambiguity, it comes from the use of the term "predeclared
type". As you point out, there is a section on predeclared identifiers
<https://golang.org/ref/spec#Predeclared_identifiers>, but this includes a
number of identifiers which are unambiguously "defined types" (such as
"int"). So I don't see how "predeclared type" contradicts or cancels out
"defined type". As far as I can see, "error" is a defined type, which
happens to have been predeclared or implicitly declared in the universe
block.
> at the end of the day, names matter, so we absolutely should use speaking
names with intuitive understanding such as "defined type" and
"type-definition"
A rose by any other name etc. Suppose we changed the terminology to
something silly, let's say "fluffy type", which avoids questions like "who
defined it? when was it defined?" The spec then becomes:
A type definition creates a new, distinct type with the same underlying type
<https://golang.org/ref/spec#Types> and operations as the given type, and
binds an identifier to it.
TypeDef = identifier <https://golang.org/ref/spec#identifier> Type
<https://golang.org/ref/spec#Type> .
The new type is called a *fluffy type*. It is different
<https://golang.org/ref/spec#Type_identity> from any other type, including
the type it is created from.
However, not all fluffy types are the result of type definitions, and to me
this is unclear without a "language lawyer" reading. As has already been
suggested, it would be helpful to include a definition:
> fluffy 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")
I agree with this apart from "except error", since I still see nothing that
says error 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/a6b9729a-2da0-40b9-bfb9-a7714aa6457c%40googlegroups.com.
