On Friday, 8 May 2020 21:58:42 UTC+1, Axel Wagner wrote:
>
> • The section on error <https://golang.org/ref/spec#Errors> *doesn't*
> specifically point this out. This, really, is where we can argue about
> reading the spec.
> - It doesn't use the specific word "defined type" at least and it doesn't
> link to type definitions, as the other sections doing this. IMO this is an
> argument that it's not a defined type per spec
> - However, it does actually use a type definition to define the type,
> which is an argument that it *is* a defined type per spec (i.e. it conforms
> to the general definition even without specific mention).
>
>
The term "defined type" doesn't mean that there must be a corresponding
type declaration/definition. "int" is a "defined type", but you cannot
write
type int int
I believe this is what you were saying when you said "I'd argue that there
is no type declaration that you could point to for saying they conform to
the definition", and I agree. However, the spec doesn't actually say that
every "defined type" must have a corresponding definition - only that type
definitions are a way to create *new* defined types.
Where I strongly agree with you is that whenever you follow a hyperlink to
"defined type", it takes you to the section on type definitions.
Effectively, the term "defined type" is not actually defined(*) in its own
right, except in terms of the side effect of a type definition. It says
that a "type definition" is a way to bring a new defined type into
existence - but as you noted, there are pre-existing defined types (but not
mentioned until later). I suspect what has happened here is that it
formerly said "named type" in which case it would have been much clearer.
I do think it would be helpful to be more up-front that the built-in
(underlying) types are also defined types. Otherwise it's easy to assume
that "defined type" means "user-defined type" - anything defined *in terms
of* the system underlying types - which is not true. Again, when it said
"named types", that problem would not have existed: it's clear that the
type "int" has the name "int". Whilst the spec is still valid, it
certainly now has the flavour of requiring a pedantic / language lawyer
interpretation.
As regards error, it says:
The predeclared type error is defined as
type error interface {
Error() string
}
I don't think that implies there is a specific class of type which is a
"predeclared type", in the same sense as there is a specific "defined type"
(*). It's just saying that this type has already been declared, in a
hidden preamble to the user code.
Secondly, even if there were a specific kind of type which is a
"predeclared type", I do not think this would make it mutually exclusive
with "defined type".
Therefore, I don't think this contradicts the earlier definition of
"defined type", and by that definition, I conclude that "error" is a
"defined type". I suppose it could instead say "The predefined type
error...", but that would also be confusing because it's not the fact that
it's a "defined type" that matters, it's the fact that it has been declared
and is available in all scopes.
In my opinion, clarity is not helped by having overlapping terms type
definitions <https://golang.org/ref/spec#Type_definitions> and type
declarations <https://golang.org/ref/spec#Type_declarations>. "Type
declarations" is the parent, with "Alias declarations" and "Type
definitions" as the children. Hence that code for "error" is both a type
declaration (general, meaning it brings a type into existence) and a type
definition (specific, meaning the result is not-an-alias, but is a "defined
type").
Regards,
Brian.
(*) What I want to say is: in the spec, the term "defined type" has/has not
been explicitly defined. This is where English is tripping me up, as I
would like to avoid re-using the word "defined", but cannot think of a good
alternative.
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/988760bc-661a-4de2-af7d-7c251f082df7%40googlegroups.com.
