On Sun, Oct 2, 2016 at 10:07 AM, T L <tapir....@gmail.com> wrote: > Ok, in fact, this is really a problem about how to comprehend the words in > go spec. > > There are two different interpretations of the words for the following > two questions, > 1. what does "the same type-spec" mean? > 2. what does "two named types" mean? > > Your interpretations: > 1. "the same type-spec" <=> the same existence of the type declaration. >
There is no other equivalence relation defined for type-specs, so understanding this as the identity-relation (every thing is the same as itself and different from every other) seems like an obvious and correct interpretation. I.e. two type-specs with the same name and structure are still not the same; they create different nodes in the AST, so why would they be the same, unless stated otherwise? > 2. "two named types" may refer two occurrences of a type. In your example, > https://play.golang.org/p/grhDxuVjeP, there are two As in "A(42)", you > call them "two named types". > This understanding is required. Type identity is not useful on it's own, it's only used to determine assignability, conversions and interface-equality (and maybe other things I'm missing). The rules for interface-comparison say (roughly), that an interface i1 containing a variable x1 of type t1 is equal to an interface (i2, x2, t2) if and only if t1 is identical to t2, that type is comparable and x1 == x2, so to make sense of this you need to allow to check two identical or not identical types for identity. Or, if you prefer: To define an equivalence relation ~ you must say which pairs (x,y) with x,y∈M fulfill x~y. In particular, you must have x~x. So, in this definition of an equivalence relation of types, you naturally must allow both checked elements to be the same. My interpretations: > 1. "the same type-spec" <=> same type-specs literally > Exactly. > 2. "two named types" means two types come from different type-specs. > So… according to your supposed definition, would two types from the same type-spec (as in, the same node in the AST) be identical, or not? You are trying to define an equivalence relation, you need to define it on *every* pair (t1, t2). > If there are two occurrences of a type, they can't be called "two named > types". In your example, https://play.golang.org/p/grhDxuVjeP, the two As > in "A(42)" are just two occurrences of a same type. I feel it is > inappropriate to say they are "two named types". > I suggest reading the definition of an equivalence relation <https://en.wikipedia.org/wiki/Equivalence_relation#Definition>. In particular, you *must* have x = y ⇒ x ~ y so if you don't handle the x = y case in your definition, you are not defining an equivalence relation. The spec *must* mention what happens when you compare two types from the same type-spec for type-identity, to give a full definition. It has the additional advantage that by mentioning it in this concise manner, you deal with a whole class of type-identities (all that involve named types) in one short sentence. > > > On Sunday, October 2, 2016 at 3:03:38 PM UTC+8, Axel Wagner wrote: >> >> So, I don't really get what's the problem here, tbh. The spec seams >> perfectly fine as it is right now to me. >> >> * If two named types come from different type-specs, they are not treated >> as identical. We covered how that can happen. >> * If two named types come from the same type-spec, then they are >> identical. The necessity of this should also be clear: >> https://play.golang.org/p/grhDxuVjeP >> >> So, what exactly is the issue here? Yes, it is not possible to declare >> two distinct types with the same type-spec or two identical types with the >> same type-spec, but clearly, if that sentence wasn't in the spec, above >> comparison would need to equal false (as the types would not be identical). >> >> I don't think there is any ambiguity or lack of clarity here. >> >> On Sun, Oct 2, 2016 at 7:08 AM, T L <tapi...@gmail.com> wrote: >> >>> >>> >>> On Sunday, October 2, 2016 at 12:24:24 PM UTC+8, Ian Lance Taylor wrote: >>> >>>> On Sat, Oct 1, 2016 at 9:21 PM, T L <tapi...@gmail.com> wrote: >>>> > >>>> > On Sunday, October 2, 2016 at 12:17:05 PM UTC+8, Ian Lance Taylor >>>> wrote: >>>> >> >>>> >> On Sat, Oct 1, 2016 at 10:56 AM, T L <tapi...@gmail.com> wrote: >>>> >> > >>>> >> > On Sunday, October 2, 2016 at 12:38:00 AM UTC+8, Ian Lance Taylor >>>> wrote: >>>> >> >> >>>> >> >> On Sat, Oct 1, 2016 at 8:55 AM, T L <tapi...@gmail.com> wrote: >>>> >> >> > >>>> >> >> > On Saturday, October 1, 2016 at 11:29:35 PM UTC+8, Axel Wagner >>>> wrote: >>>> >> >> >> >>>> >> >> >> It *is* possible to define two named types with the same name >>>> (which >>>> >> >> >> are >>>> >> >> >> not identical according to the spec): >>>> >> >> >> https://play.golang.org/p/PmkcvdNQnx >>>> >> >> > >>>> >> >> > >>>> >> >> > Oh, never know we can define local types! >>>> >> >> > >>>> >> >> > But, from my understanding, according to the spec, the two >>>> local X >>>> >> >> > types >>>> >> >> > are >>>> >> >> > identical. >>>> >> >> > But the compiler doesn't think so. >>>> >> >> > A compiler bug? >>>> >> >> >>>> >> >> I'm sorry, I don't follow your argument. The spec says, as >>>> you've >>>> >> >> already quoted, "Two named types are identical if their type >>>> names >>>> >> >> originate in the same TypeSpec." In the playground example >>>> above, the >>>> >> >> two types named "X" do not originate in the same TypeSpec, so >>>> they are >>>> >> >> not identical. >>>> >> > >>>> >> > Then could you provide an example two identical custom named types >>>> >> > originate >>>> >> > in the same TypeSpec? >>>> >> >>>> >> I don't know what it means to have two identical custom named types. >>>> >> When type T1 and type T2 are identical, they are the same type. >>>> When >>>> >> they are identical named types, they have the same name, so we are >>>> >> talking about types T and T. The question is: when is type T >>>> >> identical to type T? The answer is: when both instances of T >>>> >> originate in the same TypeSpec. And that answer makes sense, >>>> because >>>> >> as we saw above it is entirely possible to have two types named T >>>> that >>>> >> do not originate in the same TypeSpec, and those types are not >>>> >> identical. >>>> > >>>> > >>>> > Copied from this issue thread, https://github.com/golang/go/ >>>> issues/17310 >>>> > >>>> > My English is really not good,..., I think the text "originate in the >>>> same >>>> > TypeSpec" should be changed to "originate in same one TypeSpec" >>>> >>>> I'm sorry, in my opinion that would not be good English. >>>> >>>> Ian >>>> >>> >>> ;D >>> >>> ok, my current understanding is, the whole meaningfulness of this line >>> in go spec >>> >>> Two named types <https://golang.org/ref/spec#Types> are identical if >>> their type names originate in the same TypeSpec >>> <https://golang.org/ref/spec#Type_declarations>. >>> >>> is to explain in the following code >>> >>> type T0 AnotherType >>> >>> >>> T0 and T0 are identical. >>> >>> >>> -- >>> 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...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
