Dan: I don't know why you are talking about "named type". The nomenclature is outdated and obsoleted by "defined type". The only reason I see to still use it is so you can make an argument that "it has a name" means "it's a defined type" - which isn't even a correct argument anymore since type aliases can give non-defined types names. That's the entire reason the term was abandoned. The section you point to *is* however still relevant - that's why I quoted it myself in my first message. It *does* contain one definition of what a "defined type" is, by saying that a type definition creates one.
Brian: If you agree with that, […] I do agree. I actually made this argument myself upthread. I'm TBQH a bit exasperated here. Several intelligent people are seemingly (to me) ignoring what I actually wrote. And I'm fully willing to take the blame on this and accept that I wasn't being clear with what I've written or that I'm misreading what y'all are writing. I just I really don't understand how. I explicitly stated, that an argument can be made that the fact that `error` is defined in terms of a type definition in the spec, means it is a defined type. For example, my very first response to you contains the sentence 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). And in regards to: then the question hinges on whether the built-in error interface being > "predeclared" somehow emasculates its "defined type" nature Why are you bringing up "predeclared" here? I, at least, certainly never tried to pose this question (I don't think anyone ever did). I was only responding to people telling me that error is a defined type *because* it is predeclared (and hence has a name and hence is a named type…) and that's just not a valid argument. But me saying "¬(predeclared⇒defined)" is not the same as me saying "predeclared⇒¬defined". Those are two very different statements and I earnestly do not understand how what I said can be interpreted as the latter. So, to once again be absolutely clear: * I agree that there's a valid argument to be made that `error` is a defined type according to the spec. * I initially thought the spec *might* not say errors is a defined type (specifically, because it doesn't use the term "defined type" with a link to type-definitions, as it does for every other predeclared defined type). * I then realized that there are various arguments to be made to prove that it does and that some of those have counter-arguments. * I believed (from the start) that either way, this argument isn't necessary if the Errors-section of the spec was changed to, for example: The predeclared type error is defined > <https://golang.org/ref/spec#Type_definitions> as > type error interface { > Error() string > } (to state the obvious: There is no change in the text here. All I did was add a link to the word "defined") I don't even superduper think it needs to be changed. I'm just confused by people seemingly arguing past me and because I have a pathological need to find common ground, this sort of DoSes my brain :) And… lastly, just because I agree with this apart from "except error", since I still see nothing that > says error is not a defined type. Note that* in the blurb you quoted*, I said that we can simply say "or the predeclared types", if the error ambiguity is resolved. If the Errors section is clarified, that would resolve that. If it's decided that the existing argument is enough, that would also resolve it. I feel the former is preferable, but it's definitely a mole hill that has seen far more than enough blood shed. On Sat, May 9, 2020 at 3:06 PM Brian Candler <b.cand...@pobox.com> wrote: > > 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 > <https://groups.google.com/d/msgid/golang-nuts/a6b9729a-2da0-40b9-bfb9-a7714aa6457c%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/CAEkBMfGwpAFXRvtu%3DsT9uUnQZUkGp740j6ssDuttXHfD3BuP0w%40mail.gmail.com.
