Thanks for the explanation. I would admit, my interpretation of some English words and definitions may be wrong. The main reason would be my English is not good, and maybe also some culture reasons here.
Thank all also for the patience! On Sunday, October 2, 2016 at 5:14:40 PM UTC+8, Axel Wagner wrote: > > On Sun, Oct 2, 2016 at 10:07 AM, T L <tapi...@gmail.com <javascript:>> > 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...@googlegroups.com <javascript:>. >> 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.
