> > Every name that represents a type and does not stand for a type alias > is a defined, formerly named type. The essence is in the existence of > the name for the type. If it's declared in user code of magically by > the compiler does not matter.
Can you tell me where the spec says any of this? 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". So what you say may very well be true, but unless you can show how it arises from the spec, I don't really see what it's contributing. And, FTR, the essence is certainly not the existence of the name - otherwise you wouldn't have to explicitly exclude type aliases. Just to show that waving hands at the question isn't really useful. I suspect what has happened here is that it formerly said "named type" in > which case it would have been much clearer. […] Again, when it said "named types", that problem would not have existed: > it's clear that the type "int" has the name "int". To re-iterate: Before type-aliases, this was true. But today, the current discussion is created by an ambiguity between "a defined type" and "a type which has a definition" and replacing that with the ambiguity between "a named type" and "a type which has a name" isn't clearer - a type alias is a name for a type. I don't think that implies there is a specific class of type which is a > "predeclared type", The spec does have the specific notion of a predeclared identifier <https://golang.org/ref/spec#Predeclared_identifiers>, and `error` is one of them. This doesn't contradict anything you say, I just wanted to point out that I don't think the use of "the predeclared type" is ambiguous in its meaning here - "predeclared" as an adjective has a language-level meaning. "defined" as an adjective has 1. a colloquial meaning and 2. a language-level meaning, but only when preceding "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 don't understand this argument. The question is if it *matches* a definition, not if it specifically contradicts it. If you want to know if ℤ is a Ring, you don't say "nothing about the definition of ℤ says it's not a Ring, therefore I conclude it is a Ring" - you look up the definition for being a Ring and prove that ℤ matches it. 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. No, it is specifically not. What matters is if it is a "defined type" - which is a specific term in the spec used to ascribe special behavior to some types but not others. That's also why it wouldn't help if it said "predefined type" - this is not the term used in the spec to determine (for example) type identity and assignability. To take a page out of Hilbert's book: We should be able to say "Chair" instead of "type-definition" and "Bierseidel" instead of "defined type" and still get a perfectly consistent spec. It's just a name. That would then remove any ambiguity when using the word "define" in a sentence and it would prevent any confusion of semantic overlap with "predeclared". And for the most part, you *can* do this replacement. You can then ask if error was a Bierseidel under this replacement. It can be argued it would be, at the end of the day, because the section would read "The predeclared type error is defined as `type error interface { Error() string }`" - so its definition would still be a Chair, which definitionally creates Bierseidels. I still feel it might be cleaner, to not rely on this argument and just explicitly add "`error` is a Bierseidel" as well. Of course, the last paragraph reads ridiculously - 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". But once you *can* do the replacement without loss of information, you have at least avoided all confusion between the colloquial verb "define" and the specific language-level construct of a "defined type". In my opinion, clarity is not helped by having overlapping terms type > definitions and type declarations. Personally, given that any type definition is a type declaration - and given that both are syntactical constructs and thus unambiguously defined by the grammar - I don't find this super problematic. On Sat, May 9, 2020 at 11:35 AM Brian Candler <b.cand...@pobox.com> wrote: > From a language user's point of view, the following understanding seems to > work: > > - A named ("defined") type has one or more names ("identifiers") > - A type definition creates a new named type, distinct from all others > - An alias declaration adds a new name to an existing type > > This does beg the question: > > type Foo int > type Bar = Foo > > var a Bar > > What is the type of 'a'? Is it "Bar", or is it > "the-type-known-as-Foo-or-Bar"? What type should error messages show? > > Testing shows that the type of a "Foo": > https://play.golang.org/p/fVpDaEN0OVG > > So my simple understanding seems sufficient, at least in this simple > case. Error messages just show the first of the (perhaps many) names that > the type has. > > -- > 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/21dc75e9-ffbd-481c-ae1b-8d8662937d2a%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/21dc75e9-ffbd-481c-ae1b-8d8662937d2a%40googlegroups.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/CAEkBMfGWnm7djVB7oVmo13sEpQPkJ%3D0H5hQxSocBfDMNhZunLg%40mail.gmail.com.
