How to define two identical named types?

[T L]

In Go spec, https://golang.org/ref/spec#Type_identity, it says:

Two named types are identical if their type names originate in the same TypeSpec.

But, in my impression, in Golang, there are only two pair types are identical: uint8 and byte, int32 and rune.
How to define custom identical named types?

[Jan Mercl]

Not possible.

--

-j

[T L]

If no two custom named types are identical, why spec says that?

[Jan Mercl]

On Sat, Oct 1, 2016 at 9:48 AM T L <tapi...@gmail.com> wrote:

> If no two custom named types are identical, why spec says that?

Because identical named types do exists. You have already listed them.

--

-j

[T L]

howerver, the byte and uint8 are defined as followings in internal go src:

type byte byte
type uint8 uint8

they don't look like originating in the same TypeSpec.

[Jan Mercl]

On Sat, Oct 1, 2016, 10:25 T L <tapi...@gmail.com> wrote:

On Saturday, October 1, 2016 at 4:02:14 PM UTC+8, Jan Mercl wrote:

On Sat, Oct 1, 2016 at 9:48 AM T L <tapi...@gmail.com> wrote:

> If no two custom named types are identical, why spec says that?

Because identical named types do exists. You have already listed them.

--

-j

howerver, the byte and uint8 are defined as followings in internal go src:

type byte byte
type uint8 uint8

Those are not definitions in "internal go src" but documentation pseudodefinitiobs of predeclared types, to make them shown in godoc.

--

-j

[T L]

Then how are they defined?

[Jan Mercl]

On Sat, Oct 1, 2016, 10:54 T L <tapi...@gmail.com> wrote:

Then how are they defined?

Discussed earlier in this thread: they are predeclared.

--

-j

[T L]

If they are predeclared, then is it meaningless to say their type names originate in the same TypeSpec?

[Jan Mercl]

On Sat, Oct 1, 2016 at 11:27 AM T L <tapi...@gmail.com> wrote:

> If they are predeclared, then is it meaningless to say their type names originate in the same TypeSpec?

I don't know why do you think it's meaningless. byte and uint8 share the same type specification, except it's not in the form of a Go source code the compiler reads in some bootstrap stage. They are predeclared, always known to the compiler. Hardcoded, if you prefer.

Here's an example in a Go compiler front end (WIP): https://github.com/cznic/gc/blob/c3bc1381b6d1fb6498e2ef9f76002fc09554b3f8/context.go#L294 Later, at line 317 and 318, the type aliases are set. You should be able to find something similar somewhere in any other Go compiler front end.

--

-j

[T L]

I don't think it is meaningless byte and uint8 share the same type spec.
I just think the text "Two named types are identical if their type names originate in the same TypeSpec." in go spec is meaningless.

[Jan Mercl]

On Sat, Oct 1, 2016 at 12:03 PM T L <tapi...@gmail.com> wrote:

> I don't think it is meaningless byte and uint8 share the same type spec. 

Great.

> I just think the text "Two named types are identical if their type names originate in the same TypeSpec." in go spec is meaningless. 

It applies to byte and uint8 and above you said you can see the meaning.

--

-j

[T L]

but we even don't know how the builtin byte and uint8 are defined?
How do you know their type names originate in the same TypeSpec?
 

[Jan Mercl]

> but we even don't know how the builtin byte and uint8 are defined?

Yes we know, see: https://golang.org/ref/spec#Numeric_types

> How do you know their type names originate in the same TypeSpec?

Because that's how the semantics of predeclared aliases are specified, regardless of no real source code definition for the type specification exists.

Let's assume named types byte and uint8 do not share the same type specification. So the compiler must reject this code (https://play.golang.org/p/EtiJNC_NIZ):

        package main

        

        func main() {

                var b byte

                var u uint8

                b = u

                _ = b

        }

       

It compiles just fine. OTOH this code (https://play.golang.org/p/Jq9eEGGUwy):

        package main

        

        type uint8 byte

        

        func main() {

                var b byte

                var u uint8

                b = u

                _ = b

        }

        

       

Is rejected because the types are not identical and assignability rules (https://golang.org/ref/spec#Assignability) demand that when both sides are named types.

Q.E.D.

--

-j

[T L]

On Saturday, October 1, 2016 at 10:07:02 PM UTC+8, Jan Mercl wrote:

> but we even don't know how the builtin byte and uint8 are defined?

Yes we know, see: https://golang.org/ref/spec#Numeric_types

I know this byte and uint8 are identical in syntax.
But they are not defined with TypeSpec style described in the go spec.
In addition to there is no ways to define identical custom named types,
so I think the text "Two named types are identical if their type names originate in the same TypeSpec." in go spec is meaningless.

Sorry, my English is not good, I have tried my best to explain my opinion.
 

[Jan Mercl]

On Sat, Oct 1, 2016 at 4:28 PM T L <tapi...@gmail.com> wrote:

> I know this byte and uint8 are identical in syntax.

They are identical semantically.

> But they are not defined with TypeSpec style described in the go spec.

It's not possible to define all predeclared Go types using Go syntax. The predeclared error type can be defined just normally, for example[0]. But there's no way how to define a byte using valid Go source code. Some basic building blocks must be predefined in every sane programming language. From those basic building blocks other types can be built in source, provided the language supports user defined types at all.

> In addition to there is no ways to define identical custom named types,
so I think the text "Two named types are identical if their type names originate in the same TypeSpec." in go spec is meaningless. 

It's been discussed earlier in this thread that without this "meaningless" specification detail a particular example program would be rejected. It is not, because of this specs sentence. How it could be meaningless then?

> Sorry, my English is not good, I have tried my best to explain my opinion.

No problem with your English ;-)

  [0]: https://github.com/cznic/gc/blob/c3bc1381b6d1fb6498e2ef9f76002fc09554b3f8/context.go#L59

--

-j

[Axel Wagner]

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

--

-j

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[T L]

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?
 

On Sat, Oct 1, 2016 at 5:03 PM, Jan Mercl <0xj...@gmail.com> wrote:

On Sat, Oct 1, 2016 at 4:28 PM T L <tapi...@gmail.com> wrote:

> I know this byte and uint8 are identical in syntax.

They are identical semantically.

> But they are not defined with TypeSpec style described in the go spec.

It's not possible to define all predeclared Go types using Go syntax. The predeclared error type can be defined just normally, for example[0]. But there's no way how to define a byte using valid Go source code. Some basic building blocks must be predefined in every sane programming language. From those basic building blocks other types can be built in source, provided the language supports user defined types at all.

> In addition to there is no ways to define identical custom named types,
so I think the text "Two named types are identical if their type names originate in the same TypeSpec." in go spec is meaningless. 

It's been discussed earlier in this thread that without this "meaningless" specification detail a particular example program would be rejected. It is not, because of this specs sentence. How it could be meaningless then?

> Sorry, my English is not good, I have tried my best to explain my opinion.

No problem with your English ;-)

  [0]: https://github.com/cznic/gc/blob/c3bc1381b6d1fb6498e2ef9f76002fc09554b3f8/context.go#L59

--

-j

--
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.

[Ian Lance Taylor]

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.

Ian

[T L]

Then could you provide an example two identical custom named types originate in the same TypeSpec?

[Jan Mercl]

On Sat, Oct 1, 2016 at 7:56 PM T L <tapi...@gmail.com> wrote:

> Then could you provide an example two identical custom named types originate in the same TypeSpec?

Answer is in the first response to the OP.

--

-j

[T L]

I filed an issue here: https://github.com/golang/go/issues/17310
but griesemer closed it.
Waiting for griesemer to make more explanation here.

On Saturday, October 1, 2016 at 11:29:35 PM UTC+8, Axel Wagner wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[T L]

I feel we are in two parallel spaces. :)
 

--

-j

[Matt Harden]

I do think that T L has a point. The spec defines the syntax of the language, and TypeSpec refers to a syntactical construct. It is not possible in the syntax of the language to create two named types that originate in the same TypeSpec. We seem to be saying that uint8 and byte originate in the same "TypeSpec", but the "TypeSpec" referred to there is an implementation detail of the compiler, not the syntactical construct defined in the Language Specification.

I suggest the sentence be changed but not eliminated, because it is good to point out that two named types cannot be identical if either or both were created in Go code. Perhaps something like "Two named types are never identical, except for the type aliases byte and rune, which are identical to uint8 and uint32 respectively."

--

[Ian Lance Taylor]

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.

I know this conversation has had some discussion of the alias types
"byte" and "rune". The spec defines those types as aliases. It is
not the case that there is a type "byte" that is identical to the type
"uint8". Instead, the name "byte" is an alias for the type "uint8".

It's also worth considering this in connection with proposal #16339,
which introduces user-defined aliases, including type aliases.

Ian

[T L]

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"

 

[T L]

On Sunday, October 2, 2016 at 11:34:41 AM UTC+8, Matt Harden wrote:

I do think that T L has a point. The spec defines the syntax of the language, and TypeSpec refers to a syntactical construct. It is not possible in the syntax of the language to create two named types that originate in the same TypeSpec. We seem to be saying that uint8 and byte originate in the same "TypeSpec", but the "TypeSpec" referred to there is an implementation detail of the compiler, not the syntactical construct defined in the Language Specification.

I suggest the sentence be changed but not eliminated, because it is good to point out that two named types cannot be identical if either or both were created in Go code. Perhaps something like "Two named types are never identical, except for the type aliases byte and rune, which are identical to uint8 and uint32 respectively."

This is quite clear, much better than the current description.
 

[Ian Lance Taylor]

I'm sorry, in my opinion that would not be good English.

Ian

[T L]

;D

ok, my current understanding is, the whole meaningfulness of this line in go spec

Two named types are identical if their type names originate in the same TypeSpec.

is to explain in the following code

type T0 AnotherType

T0 and T0 are identical.

[Axel Wagner]

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.

--
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+unsubscribe@googlegroups.com.

[T L]

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.
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".

My interpretations:
1. "the same type-spec" <=> same type-specs literally
2. "two named types" means two types come from different type-specs. 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".

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Axel Wagner]

On Sun, Oct 2, 2016 at 10:07 AM, T L <tapi...@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. 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.

 

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

[T L]

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!

[Marvin Renich]

* Matt Harden <matt....@gmail.com> [161001 23:34]:

> I do think that T L has a point. The spec defines the syntax of the
> language, and TypeSpec refers to a syntactical construct. It is not
> possible in the syntax of the language to create two named types that
> originate in the same TypeSpec. We seem to be saying that uint8 and byte
> originate in the same "TypeSpec", but the "TypeSpec" referred to there is
> an implementation detail of the compiler, not the syntactical construct
> defined in the Language Specification.

Does anyone remember if there was a time when TypeSpec was defined as

TypeSpec = IdentifierList Type .

instead of the current

TypeSpec = identifier Type .

This would give a clear reason why the wording under type identity is
the way it is. I don't remember such a definition, and I've been
following Go since before Version 1, but not since the beginning, so
this is at least conceivable. It's also possible that the Go authors
were considering such a definition, and part of the spec was written,
but the idea was thrown out as unnecessary and adding extra complexity,
accidentally leaving an artifact of a considered, but discarded, design
detail.

...Marvin

[T L]

I just checked the history of go spec: https://github.com/golang/go/commits/master/doc/go_spec.html?after=mYQZV1%2BzTdUijP2zU6cxhOKduNorNTI0
It looks there is only one main change, from

TypeDecl = "type" ( TypeSpec | "(" [ TypeSpecList ] ")" ) .
TypeSpecList = TypeSpec { ";" TypeSpec } [ ";" ] .

TypeSpec = identifier Type .

to

TypeDecl = "type" ( TypeSpec | "(" { TypeSpec ";" } ")" ) .

TypeSpec = identifier Type .

so go authors may really think "T0 and T0" is worth mentioning in go spec.

BTW, I think it would be less confusing if "originate in the same TypeSpec" changed to "originate in the same TypeDecl".

[Axel Wagner]

Which would imply that something like this

type (

    Foo int

    Foo int

)

might be legal. I don't understand (and thusly disagree) why that would be in any sense "less confusing".

--
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+unsubscribe@googlegroups.com.

[T L]

On Monday, October 3, 2016 at 2:42:30 PM UTC+8, Axel Wagner wrote:

Which would imply that something like this

type (

    Foo int

    Foo int

)

might be legal. I don't understand (and thusly disagree) why that would be in any sense "less confusing".

I confuse again.

In your before comments, you interpretate "the same type-spec" must be the only occurrence of a type-spec, and can't be two occurrences of same type-spec in texts.
But now you interpretate "the same type-decl" can be two occurrences of same type-decl in texts.

I really don't know my English understanding is right or not, now, again.

 

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[T L]

On Monday, October 3, 2016 at 4:59:26 PM UTC+8, T L wrote:

On Monday, October 3, 2016 at 2:42:30 PM UTC+8, Axel Wagner wrote:

Which would imply that something like this

type (

    Foo int

    Foo int

)

might be legal. I don't understand (and thusly disagree) why that would be in any sense "less confusing".

I confuse again.

In your before comments, you interpretate "the same type-spec" must be the only occurrence of a type-spec, and can't be two occurrences of same type-spec in texts.
But now you interpretate "the same type-decl" can be two occurrences of same type-decl in texts.

I really don't know my English understanding is right or not, now, again.

Besides this, in fact, in the example you provide, https://play.golang.org/p/PmkcvdNQnx,
there are two same (in texts) type declarations, they are both legal.

And why does "the same type-decl" will imply "type (Foo int; Foo int)", but "the same type-spec" will not make the imply?
 

[Axel Wagner]

The only difference between talking about "TypeDecl" and "TypeSpec" is, that it distinguishes

type (

    Foo int

    Bar int

)

from

type Foo int

type Bar int

so I don't see how it helps and if anything it makes things more confusing, because one type declaration can *actually* define multiple types, whereas one type spec can only ever define exactly one type. By talking about type declarations instead of type specs, you seem to imply that those two would behave differently, which they don't.

So not only do I consider it more confusing, it also is completely incorrect; Foo and Bar in both cases are distinct types and should be distinct types. However, in the former case, they are two named types that originate in the same type declaration so according to your proposed language they would be identical.

Besides this, in fact, in the example you provide, https://play.golang.org/p/PmkcvdNQnx,
there are two same (in texts) type declarations, they are both legal.

They are not the same, they are different. They are also in different type specs. And if you where the insist to call the two type declarations the same, then the type specs are "same" in exactly the same sense.

And why does "the same type-decl" will imply "type (Foo int; Foo int)", but "the same type-spec" will not make the imply?

Because both Foo are in the same type declaration, but not in the same type spec. If the type spec language would imply anything of the sorts, it would be that you could define two types in the same type-spec, which is clearly impossible.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

[T L]

On Monday, October 3, 2016 at 5:30:35 PM UTC+8, Axel Wagner wrote:

The only difference between talking about "TypeDecl" and "TypeSpec" is, that it distinguishes

type (

    Foo int

    Bar int

)

from

type Foo int

type Bar int

ok, it looks the misunderstanding comes I thought "type (Foo int; Bar int)" is a declaration group, which contains two declarations.
But, instead, now in go spec, the definition of type declaration is container which contains many type specifications.

In fact, I feel this is some weird, for the word "type specification" is seldom orally used in practice.