On Fri, May 8, 2020 at 7:32 PM Brian Candler <b.cand...@pobox.com> wrote:
> Could you explain why error is not a defined type? Is it something
> special about "error" specifically, or something about interface types in
> general?
>
First, the disclaimer again: I'm now coming around that there *is* a
reading of a spec that error is a defined type. I also think it could be
more explicit. So anything I say now is not to language-lawyer the spec,
but to explain why I think it could be made more precise.
I said `error` is not a defined type ("the spec can be read as saying it
isn't") based on the quotes I posted above.
• The section on type definitions
<https://golang.org/ref/spec#Type_definitions>, which is IMO closest to a
definition of "defined type" says that a type declaration creates a new
type, which is a defined type.
• The section on predeclared identifiers
<https://golang.org/ref/spec#Predeclared_identifiers> doesn't say anything
really on the topic. Note, that even with a surrounding virtual
universe-block, you can't actually write down a syntactical type
declaration for int/int32/… - they have to be built into the language. I'd
argue that there is no type declaration that you could point to for saying
they conform to the definition.
• OTOH, the sections introducing bool
<https://golang.org/ref/spec#Boolean_types>, numeric types
<https://golang.org/ref/spec#Numeric_types> and string
<https://golang.org/ref/spec#String_types> *specifically point out* that
these types are defined types. So even if they don't conform to the
definition in and off itself, the spec does state they are defined types.
This also, FWIW, gives a hint that there is a need to state so. Being
predeclared doesn't make them so.
• 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 only reason I mentioned `error` being an interface, is because I was
wondering *why* the spec doesn't specifically mention that it is a defined
type, given that it does so for the other types. I guessed that it might
not be necessary, because it's an interface - that guess was wrong, I think.
So, in conclusion:
• I believe it would at least be clearer that `error` is a defined type, if
the word "defined" in the section on `error` would link to the section on
type-definitions, or would mention the specific term "defined type".
• I believe the section on type definitions could clarify, that defined
types are not *only* introduced by type-definitions, but also include
predeclared types. There's no ambiguity in regards to this, but it would
IMO be clearer - it's natural to arrive at this section via the various
"defined types" links and getting an actual comprehensive answer on what
they are would be helpful.
Informally, I think of defined types as "named types".
Well, that's what the nomenclature used to be. It was changed, because the
term got ambiguous and confusing once type-aliases got introduced. Turns
out, it's still confusing because people confuse "defined" and "declared".
--
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/CAEkBMfFMTNBMKUU22GkWWeDOfs5%2B7aXxBta1ad%3D5n7XFV-LOYw%40mail.gmail.com.
