In https://golang.org/ref/spec#Types a Type is defined in terms of a
TypeName a TypeLit or a (Type). A TypeName is what makes a type a named
type. This is defined as either an identifier or a qualified
identifier. For the discussion here we can ignore the latter. An
identifier contains letters and unicode digits and must start with a
letter. From this we can see that an, e.g., int is a named type. The
alternative is a TypeLit, which is marked with a variety of keywords or
type punctuation (*, [] and [n]), these are unnamed types.
On Sat, 2020-05-09 at 12:51 +0200, 'Axel Wagner' via golang-nuts wrote:
> > 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,
> 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/df58eeee48ef279658878b3633bb304cfa854bd3.camel%40kortschak.io.
