Re: [go-nuts] Re: An mistake in tip spec?

[Brian Candler]

Now my head is spinning:

interface{ int; m() }  // int (but type set is empty because int 
has no method m)
interface{ ~int; m() } // int (but type set is infinite because 
there are many int types with method m)

On Saturday, 8 January 2022 at 02:32:35 UTC gri wrote:

> Indeed. There's no shortcuts possible here. Hopefully this works better 
> (and closely matches the implementation):
> https://go-review.googlesource.com/c/go/+/376834
> - gri
>
> On Thu, Jan 6, 2022 at 10:08 PM Axel Wagner  
> wrote:
>
>> On Fri, Jan 7, 2022 at 2:35 AM 'gri' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> Thanks for raising this issue. This is clearly a bug in the spec, or at 
>>> the very least "an imprecision". Hopefully this is better: 
>>> https://go-review.googlesource.com/c/go/+/375799 .
>>
>>
>> ISTM this still fails for `int | any`, which according to the rules has 
>> specific types `int`, but should have no specific types.
>>  
>>
>>>
>>> The set of specific types is an approximation for the actual type set. 
>>> In practice we only need to consider those explicitly mentioned types. If 
>>> the type set is infinite, we can't do much (with respect to operations). To 
>>> make that simple elsewhere in the spec we want the set of specific types be 
>>> empty in that case. An alternative approach might be to say the set of 
>>> specific types is infinite in that case and exclude such infinite sets 
>>> where we look at specific types.
>>>
>>> - gri
>>>
>>> On Thursday, January 6, 2022 at 1:23:31 PM UTC-8 
>>> axel.wa...@googlemail.com wrote:
>>>
 The more I think about it, the more I'm inclined to agree that there is 
 something wrong with the spec (and maybe the idea of sets of specific 
 types 
 in general).
 Because what's the set of specific types of `interface { int | any }`? 
 From the definition, it should be `int` - the union with an empty set is a 
 no-op. But the *type set* of that is all types. Which means that this 
 should be allowed, as per the spec, which is obviously nonsense:

 type C interface {
 int | any
 }

 func F[T C](v T) {
 fmt.Println(int(v))
 }

 So, logically, the type set of an interface type without type elements 
 should really be the set of all types (or rather "the set of all 
 underlying 
 types"), not the empty set, for the algorithm to make sense. In that case, 
 the specific types of `int | any` are the set of all types and the 
 specific 
 types of `int ; any` is `int`.

 I'm not sure if this would be sound, though, as we now get back to the 
 situation of reducing back from the set of all types to some subset. Maybe 
 the new restrictions put in place (namely that interfaces with methods 
 can't appear in unions) are enough to make this easy to manage. I don't 
 know. Thinking through that would take time.

 On Thu, Jan 6, 2022 at 8:37 PM Ian Lance Taylor  
 wrote:

> On Thu, Jan 6, 2022 at 11:32 AM Axel Wagner
>  wrote:
> >
> > On Thu, Jan 6, 2022 at 8:18 PM Ian Lance Taylor  
> wrote:
> >>
> >> On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts
> >>  wrote:
> >> >
> >> > • From the definition of type elements, we can see that an 
> embedded interface type is a type element. Therefore, `any` is a type 
> element.
> >> > • `any` is an alias for `interface{}`, therefore it is a type 
> without any type elements, therefore the set of its specific types is 
> empty 
> ("For an interface with no type elements, 𝑆 is the empty set.").
> >> > • `interface{ int; any }` is a type with two type elements. "For 
> an interface with type elements, 𝑆 is the intersection of the specific 
> types of its type elements.". Intersecting with an empty set (the 
> specific 
> types of `any`) gives an empty set
> >> > • Therefore, the set of specific types of `interface{ int; any }` 
> is the empty set.
> >>
> >> That doesn't seem right.  "any" is an interface type and writing
> >> "interface { any }" just embeds the empty interface, which has no
> >> effect.
> >
> >
> > I think it has no effect on the type set. But it has an effect on 
> the set of specific types.
> >
> > I believe both the rule "for an interface type without type elements 
> S is empty" and the rule "for an interface type with type elements, S is 
> the intersection of the specific types of its type elements" are vital to 
> the working of S - they are, what makes the set easily computable.
> >
> > To answer the question from your comment in the CL: I believe the 
> grammar is very unambiguous about `any` being a type element:
> >
> >> InterfaceType = "interface" "{" { InterfaceElem ";" } "}" .
> >> InterfaceElem = MethodElem | TypeElem .
> >> MethodElem = MethodName Signature .
>>

Re: [go-nuts] Re: An mistake in tip spec?

['Robert Griesemer' via golang-nuts]

Indeed. There's no shortcuts possible here. Hopefully this works better
(and closely matches the implementation):
https://go-review.googlesource.com/c/go/+/376834
- gri

On Thu, Jan 6, 2022 at 10:08 PM Axel Wagner 
wrote:

> On Fri, Jan 7, 2022 at 2:35 AM 'gri' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> Thanks for raising this issue. This is clearly a bug in the spec, or at
>> the very least "an imprecision". Hopefully this is better:
>> https://go-review.googlesource.com/c/go/+/375799 .
>
>
> ISTM this still fails for `int | any`, which according to the rules has
> specific types `int`, but should have no specific types.
>
>
>>
>> The set of specific types is an approximation for the actual type set. In
>> practice we only need to consider those explicitly mentioned types. If the
>> type set is infinite, we can't do much (with respect to operations). To
>> make that simple elsewhere in the spec we want the set of specific types be
>> empty in that case. An alternative approach might be to say the set of
>> specific types is infinite in that case and exclude such infinite sets
>> where we look at specific types.
>>
>> - gri
>>
>> On Thursday, January 6, 2022 at 1:23:31 PM UTC-8
>> axel.wa...@googlemail.com wrote:
>>
>>> The more I think about it, the more I'm inclined to agree that there is
>>> something wrong with the spec (and maybe the idea of sets of specific types
>>> in general).
>>> Because what's the set of specific types of `interface { int | any }`?
>>> From the definition, it should be `int` - the union with an empty set is a
>>> no-op. But the *type set* of that is all types. Which means that this
>>> should be allowed, as per the spec, which is obviously nonsense:
>>>
>>> type C interface {
>>> int | any
>>> }
>>>
>>> func F[T C](v T) {
>>> fmt.Println(int(v))
>>> }
>>>
>>> So, logically, the type set of an interface type without type elements
>>> should really be the set of all types (or rather "the set of all underlying
>>> types"), not the empty set, for the algorithm to make sense. In that case,
>>> the specific types of `int | any` are the set of all types and the specific
>>> types of `int ; any` is `int`.
>>>
>>> I'm not sure if this would be sound, though, as we now get back to the
>>> situation of reducing back from the set of all types to some subset. Maybe
>>> the new restrictions put in place (namely that interfaces with methods
>>> can't appear in unions) are enough to make this easy to manage. I don't
>>> know. Thinking through that would take time.
>>>
>>> On Thu, Jan 6, 2022 at 8:37 PM Ian Lance Taylor 
>>> wrote:
>>>
 On Thu, Jan 6, 2022 at 11:32 AM Axel Wagner
  wrote:
 >
 > On Thu, Jan 6, 2022 at 8:18 PM Ian Lance Taylor 
 wrote:
 >>
 >> On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts
 >>  wrote:
 >> >
 >> > • From the definition of type elements, we can see that an
 embedded interface type is a type element. Therefore, `any` is a type
 element.
 >> > • `any` is an alias for `interface{}`, therefore it is a type
 without any type elements, therefore the set of its specific types is empty
 ("For an interface with no type elements, 𝑆 is the empty set.").
 >> > • `interface{ int; any }` is a type with two type elements. "For
 an interface with type elements, 𝑆 is the intersection of the specific
 types of its type elements.". Intersecting with an empty set (the specific
 types of `any`) gives an empty set
 >> > • Therefore, the set of specific types of `interface{ int; any }`
 is the empty set.
 >>
 >> That doesn't seem right.  "any" is an interface type and writing
 >> "interface { any }" just embeds the empty interface, which has no
 >> effect.
 >
 >
 > I think it has no effect on the type set. But it has an effect on the
 set of specific types.
 >
 > I believe both the rule "for an interface type without type elements
 S is empty" and the rule "for an interface type with type elements, S is
 the intersection of the specific types of its type elements" are vital to
 the working of S - they are, what makes the set easily computable.
 >
 > To answer the question from your comment in the CL: I believe the
 grammar is very unambiguous about `any` being a type element:
 >
 >> InterfaceType = "interface" "{" { InterfaceElem ";" } "}" .
 >> InterfaceElem = MethodElem | TypeElem .
 >> MethodElem = MethodName Signature .
 >> MethodName = identifier .
 >> TypeElem = TypeTerm { "|" TypeTerm } .
 >> TypeTerm = Type | UnderlyingType .
 >> UnderlyingType = "~" Type .
 >
 >
 > There is no signature, so it's not a MethodElem. Therefore it must be
 a TypeElem.

 Yeah, I think there is something wrong in the current spec.  It can't
 be the case that embedding an interface eliminates all specific types.

 Ian

>>> --
>> You received this m

Re: [go-nuts] Re: An mistake in tip spec?

['Axel Wagner' via golang-nuts]

On Fri, Jan 7, 2022 at 2:35 AM 'gri' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Thanks for raising this issue. This is clearly a bug in the spec, or at
> the very least "an imprecision". Hopefully this is better:
> https://go-review.googlesource.com/c/go/+/375799 .


ISTM this still fails for `int | any`, which according to the rules has
specific types `int`, but should have no specific types.


>
> The set of specific types is an approximation for the actual type set. In
> practice we only need to consider those explicitly mentioned types. If the
> type set is infinite, we can't do much (with respect to operations). To
> make that simple elsewhere in the spec we want the set of specific types be
> empty in that case. An alternative approach might be to say the set of
> specific types is infinite in that case and exclude such infinite sets
> where we look at specific types.
>
> - gri
>
> On Thursday, January 6, 2022 at 1:23:31 PM UTC-8 axel.wa...@googlemail.com
> wrote:
>
>> The more I think about it, the more I'm inclined to agree that there is
>> something wrong with the spec (and maybe the idea of sets of specific types
>> in general).
>> Because what's the set of specific types of `interface { int | any }`?
>> From the definition, it should be `int` - the union with an empty set is a
>> no-op. But the *type set* of that is all types. Which means that this
>> should be allowed, as per the spec, which is obviously nonsense:
>>
>> type C interface {
>> int | any
>> }
>>
>> func F[T C](v T) {
>> fmt.Println(int(v))
>> }
>>
>> So, logically, the type set of an interface type without type elements
>> should really be the set of all types (or rather "the set of all underlying
>> types"), not the empty set, for the algorithm to make sense. In that case,
>> the specific types of `int | any` are the set of all types and the specific
>> types of `int ; any` is `int`.
>>
>> I'm not sure if this would be sound, though, as we now get back to the
>> situation of reducing back from the set of all types to some subset. Maybe
>> the new restrictions put in place (namely that interfaces with methods
>> can't appear in unions) are enough to make this easy to manage. I don't
>> know. Thinking through that would take time.
>>
>> On Thu, Jan 6, 2022 at 8:37 PM Ian Lance Taylor  wrote:
>>
>>> On Thu, Jan 6, 2022 at 11:32 AM Axel Wagner
>>>  wrote:
>>> >
>>> > On Thu, Jan 6, 2022 at 8:18 PM Ian Lance Taylor 
>>> wrote:
>>> >>
>>> >> On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts
>>> >>  wrote:
>>> >> >
>>> >> > • From the definition of type elements, we can see that an embedded
>>> interface type is a type element. Therefore, `any` is a type element.
>>> >> > • `any` is an alias for `interface{}`, therefore it is a type
>>> without any type elements, therefore the set of its specific types is empty
>>> ("For an interface with no type elements, 𝑆 is the empty set.").
>>> >> > • `interface{ int; any }` is a type with two type elements. "For an
>>> interface with type elements, 𝑆 is the intersection of the specific types
>>> of its type elements.". Intersecting with an empty set (the specific types
>>> of `any`) gives an empty set
>>> >> > • Therefore, the set of specific types of `interface{ int; any }`
>>> is the empty set.
>>> >>
>>> >> That doesn't seem right.  "any" is an interface type and writing
>>> >> "interface { any }" just embeds the empty interface, which has no
>>> >> effect.
>>> >
>>> >
>>> > I think it has no effect on the type set. But it has an effect on the
>>> set of specific types.
>>> >
>>> > I believe both the rule "for an interface type without type elements S
>>> is empty" and the rule "for an interface type with type elements, S is the
>>> intersection of the specific types of its type elements" are vital to the
>>> working of S - they are, what makes the set easily computable.
>>> >
>>> > To answer the question from your comment in the CL: I believe the
>>> grammar is very unambiguous about `any` being a type element:
>>> >
>>> >> InterfaceType = "interface" "{" { InterfaceElem ";" } "}" .
>>> >> InterfaceElem = MethodElem | TypeElem .
>>> >> MethodElem = MethodName Signature .
>>> >> MethodName = identifier .
>>> >> TypeElem = TypeTerm { "|" TypeTerm } .
>>> >> TypeTerm = Type | UnderlyingType .
>>> >> UnderlyingType = "~" Type .
>>> >
>>> >
>>> > There is no signature, so it's not a MethodElem. Therefore it must be
>>> a TypeElem.
>>>
>>> Yeah, I think there is something wrong in the current spec.  It can't
>>> be the case that embedding an interface eliminates all specific types.
>>>
>>> Ian
>>>
>> --
> 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/d6e91c64-7a8a-4bd2-912b-3f9a1cb7333an%40googlegrou

Re: [go-nuts] Re: An mistake in tip spec?

[tapi...@gmail.com]

Thanks for the reply, gri.

The latest generics design and implementation are much more beautiful than 
I expected, though I still think there are many restrictions.

BTW, it looks the following line in spec becomes depreciated now, as now 
any type could be embedded in interfaces.

In a slightly more general form an interface T may use a (possibly 
qualified) interface type name E as an interface element. This is called 
*embedding* interface E in T.
On Friday, January 7, 2022 at 9:34:41 AM UTC+8 gri wrote:

> Thanks for raising this issue. This is clearly a bug in the spec, or at 
> the very least "an imprecision". Hopefully this is better: 
> https://go-review.googlesource.com/c/go/+/375799 .
>
> The set of specific types is an approximation for the actual type set. In 
> practice we only need to consider those explicitly mentioned types. If the 
> type set is infinite, we can't do much (with respect to operations). To 
> make that simple elsewhere in the spec we want the set of specific types be 
> empty in that case. An alternative approach might be to say the set of 
> specific types is infinite in that case and exclude such infinite sets 
> where we look at specific types.
>
> - gri
>
> On Thursday, January 6, 2022 at 1:23:31 PM UTC-8 axel.wa...@googlemail.com 
> wrote:
>
>> The more I think about it, the more I'm inclined to agree that there is 
>> something wrong with the spec (and maybe the idea of sets of specific types 
>> in general).
>> Because what's the set of specific types of `interface { int | any }`? 
>> From the definition, it should be `int` - the union with an empty set is a 
>> no-op. But the *type set* of that is all types. Which means that this 
>> should be allowed, as per the spec, which is obviously nonsense:
>>
>> type C interface {
>> int | any
>> }
>>
>> func F[T C](v T) {
>> fmt.Println(int(v))
>> }
>>
>> So, logically, the type set of an interface type without type elements 
>> should really be the set of all types (or rather "the set of all underlying 
>> types"), not the empty set, for the algorithm to make sense. In that case, 
>> the specific types of `int | any` are the set of all types and the specific 
>> types of `int ; any` is `int`.
>>
>> I'm not sure if this would be sound, though, as we now get back to the 
>> situation of reducing back from the set of all types to some subset. Maybe 
>> the new restrictions put in place (namely that interfaces with methods 
>> can't appear in unions) are enough to make this easy to manage. I don't 
>> know. Thinking through that would take time.
>>
>> On Thu, Jan 6, 2022 at 8:37 PM Ian Lance Taylor  wrote:
>>
>>> On Thu, Jan 6, 2022 at 11:32 AM Axel Wagner
>>>  wrote:
>>> >
>>> > On Thu, Jan 6, 2022 at 8:18 PM Ian Lance Taylor  
>>> wrote:
>>> >>
>>> >> On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts
>>> >>  wrote:
>>> >> >
>>> >> > • From the definition of type elements, we can see that an embedded 
>>> interface type is a type element. Therefore, `any` is a type element.
>>> >> > • `any` is an alias for `interface{}`, therefore it is a type 
>>> without any type elements, therefore the set of its specific types is empty 
>>> ("For an interface with no type elements, 𝑆 is the empty set.").
>>> >> > • `interface{ int; any }` is a type with two type elements. "For an 
>>> interface with type elements, 𝑆 is the intersection of the specific types 
>>> of its type elements.". Intersecting with an empty set (the specific types 
>>> of `any`) gives an empty set
>>> >> > • Therefore, the set of specific types of `interface{ int; any }` 
>>> is the empty set.
>>> >>
>>> >> That doesn't seem right.  "any" is an interface type and writing
>>> >> "interface { any }" just embeds the empty interface, which has no
>>> >> effect.
>>> >
>>> >
>>> > I think it has no effect on the type set. But it has an effect on the 
>>> set of specific types.
>>> >
>>> > I believe both the rule "for an interface type without type elements S 
>>> is empty" and the rule "for an interface type with type elements, S is the 
>>> intersection of the specific types of its type elements" are vital to the 
>>> working of S - they are, what makes the set easily computable.
>>> >
>>> > To answer the question from your comment in the CL: I believe the 
>>> grammar is very unambiguous about `any` being a type element:
>>> >
>>> >> InterfaceType = "interface" "{" { InterfaceElem ";" } "}" .
>>> >> InterfaceElem = MethodElem | TypeElem .
>>> >> MethodElem = MethodName Signature .
>>> >> MethodName = identifier .
>>> >> TypeElem = TypeTerm { "|" TypeTerm } .
>>> >> TypeTerm = Type | UnderlyingType .
>>> >> UnderlyingType = "~" Type .
>>> >
>>> >
>>> > There is no signature, so it's not a MethodElem. Therefore it must be 
>>> a TypeElem.
>>>
>>> Yeah, I think there is something wrong in the current spec.  It can't
>>> be the case that embedding an interface eliminates all specific types.
>>>
>>> Ian
>>>
>>

-- 
You received this message because you are 

Re: [go-nuts] Re: An mistake in tip spec?

['gri' via golang-nuts]

Thanks for raising this issue. This is clearly a bug in the spec, or at the 
very least "an imprecision". Hopefully this is 
better: https://go-review.googlesource.com/c/go/+/375799 .

The set of specific types is an approximation for the actual type set. In 
practice we only need to consider those explicitly mentioned types. If the 
type set is infinite, we can't do much (with respect to operations). To 
make that simple elsewhere in the spec we want the set of specific types be 
empty in that case. An alternative approach might be to say the set of 
specific types is infinite in that case and exclude such infinite sets 
where we look at specific types.

- gri

On Thursday, January 6, 2022 at 1:23:31 PM UTC-8 axel.wa...@googlemail.com 
wrote:

> The more I think about it, the more I'm inclined to agree that there is 
> something wrong with the spec (and maybe the idea of sets of specific types 
> in general).
> Because what's the set of specific types of `interface { int | any }`? 
> From the definition, it should be `int` - the union with an empty set is a 
> no-op. But the *type set* of that is all types. Which means that this 
> should be allowed, as per the spec, which is obviously nonsense:
>
> type C interface {
> int | any
> }
>
> func F[T C](v T) {
> fmt.Println(int(v))
> }
>
> So, logically, the type set of an interface type without type elements 
> should really be the set of all types (or rather "the set of all underlying 
> types"), not the empty set, for the algorithm to make sense. In that case, 
> the specific types of `int | any` are the set of all types and the specific 
> types of `int ; any` is `int`.
>
> I'm not sure if this would be sound, though, as we now get back to the 
> situation of reducing back from the set of all types to some subset. Maybe 
> the new restrictions put in place (namely that interfaces with methods 
> can't appear in unions) are enough to make this easy to manage. I don't 
> know. Thinking through that would take time.
>
> On Thu, Jan 6, 2022 at 8:37 PM Ian Lance Taylor  wrote:
>
>> On Thu, Jan 6, 2022 at 11:32 AM Axel Wagner
>>  wrote:
>> >
>> > On Thu, Jan 6, 2022 at 8:18 PM Ian Lance Taylor  
>> wrote:
>> >>
>> >> On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts
>> >>  wrote:
>> >> >
>> >> > • From the definition of type elements, we can see that an embedded 
>> interface type is a type element. Therefore, `any` is a type element.
>> >> > • `any` is an alias for `interface{}`, therefore it is a type 
>> without any type elements, therefore the set of its specific types is empty 
>> ("For an interface with no type elements, 𝑆 is the empty set.").
>> >> > • `interface{ int; any }` is a type with two type elements. "For an 
>> interface with type elements, 𝑆 is the intersection of the specific types 
>> of its type elements.". Intersecting with an empty set (the specific types 
>> of `any`) gives an empty set
>> >> > • Therefore, the set of specific types of `interface{ int; any }` is 
>> the empty set.
>> >>
>> >> That doesn't seem right.  "any" is an interface type and writing
>> >> "interface { any }" just embeds the empty interface, which has no
>> >> effect.
>> >
>> >
>> > I think it has no effect on the type set. But it has an effect on the 
>> set of specific types.
>> >
>> > I believe both the rule "for an interface type without type elements S 
>> is empty" and the rule "for an interface type with type elements, S is the 
>> intersection of the specific types of its type elements" are vital to the 
>> working of S - they are, what makes the set easily computable.
>> >
>> > To answer the question from your comment in the CL: I believe the 
>> grammar is very unambiguous about `any` being a type element:
>> >
>> >> InterfaceType = "interface" "{" { InterfaceElem ";" } "}" .
>> >> InterfaceElem = MethodElem | TypeElem .
>> >> MethodElem = MethodName Signature .
>> >> MethodName = identifier .
>> >> TypeElem = TypeTerm { "|" TypeTerm } .
>> >> TypeTerm = Type | UnderlyingType .
>> >> UnderlyingType = "~" Type .
>> >
>> >
>> > There is no signature, so it's not a MethodElem. Therefore it must be a 
>> TypeElem.
>>
>> Yeah, I think there is something wrong in the current spec.  It can't
>> be the case that embedding an interface eliminates all specific types.
>>
>> Ian
>>
>

-- 
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/d6e91c64-7a8a-4bd2-912b-3f9a1cb7333an%40googlegroups.com.

Re: [go-nuts] Re: An mistake in tip spec?

['Axel Wagner' via golang-nuts]

The more I think about it, the more I'm inclined to agree that there is
something wrong with the spec (and maybe the idea of sets of specific types
in general).
Because what's the set of specific types of `interface { int | any }`? From
the definition, it should be `int` - the union with an empty set is a
no-op. But the *type set* of that is all types. Which means that this
should be allowed, as per the spec, which is obviously nonsense:

type C interface {
int | any
}

func F[T C](v T) {
fmt.Println(int(v))
}

So, logically, the type set of an interface type without type elements
should really be the set of all types (or rather "the set of all underlying
types"), not the empty set, for the algorithm to make sense. In that case,
the specific types of `int | any` are the set of all types and the specific
types of `int ; any` is `int`.

I'm not sure if this would be sound, though, as we now get back to the
situation of reducing back from the set of all types to some subset. Maybe
the new restrictions put in place (namely that interfaces with methods
can't appear in unions) are enough to make this easy to manage. I don't
know. Thinking through that would take time.

On Thu, Jan 6, 2022 at 8:37 PM Ian Lance Taylor  wrote:

> On Thu, Jan 6, 2022 at 11:32 AM Axel Wagner
>  wrote:
> >
> > On Thu, Jan 6, 2022 at 8:18 PM Ian Lance Taylor  wrote:
> >>
> >> On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts
> >>  wrote:
> >> >
> >> > • From the definition of type elements, we can see that an embedded
> interface type is a type element. Therefore, `any` is a type element.
> >> > • `any` is an alias for `interface{}`, therefore it is a type without
> any type elements, therefore the set of its specific types is empty ("For
> an interface with no type elements, 𝑆 is the empty set.").
> >> > • `interface{ int; any }` is a type with two type elements. "For an
> interface with type elements, 𝑆 is the intersection of the specific types
> of its type elements.". Intersecting with an empty set (the specific types
> of `any`) gives an empty set
> >> > • Therefore, the set of specific types of `interface{ int; any }` is
> the empty set.
> >>
> >> That doesn't seem right.  "any" is an interface type and writing
> >> "interface { any }" just embeds the empty interface, which has no
> >> effect.
> >
> >
> > I think it has no effect on the type set. But it has an effect on the
> set of specific types.
> >
> > I believe both the rule "for an interface type without type elements S
> is empty" and the rule "for an interface type with type elements, S is the
> intersection of the specific types of its type elements" are vital to the
> working of S - they are, what makes the set easily computable.
> >
> > To answer the question from your comment in the CL: I believe the
> grammar is very unambiguous about `any` being a type element:
> >
> >> InterfaceType = "interface" "{" { InterfaceElem ";" } "}" .
> >> InterfaceElem = MethodElem | TypeElem .
> >> MethodElem = MethodName Signature .
> >> MethodName = identifier .
> >> TypeElem = TypeTerm { "|" TypeTerm } .
> >> TypeTerm = Type | UnderlyingType .
> >> UnderlyingType = "~" Type .
> >
> >
> > There is no signature, so it's not a MethodElem. Therefore it must be a
> TypeElem.
>
> Yeah, I think there is something wrong in the current spec.  It can't
> be the case that embedding an interface eliminates all specific types.
>
> Ian
>

-- 
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/CAEkBMfEmxAHobfcyye9bdsW3gEnu_RbbxBJ9HCtneXoe3SgZiA%40mail.gmail.com.

Re: [go-nuts] Re: An mistake in tip spec?

['Axel Wagner' via golang-nuts]

On Thu, Jan 6, 2022 at 9:14 PM Brian Candler  wrote:

> Is that necessarily true? The spec appears to have an example where the
> specific types are a superset of the type set:
>
> -
> Examples of interfaces with their specific types:
> ...
> interface{ int; m() } // int (but type set is empty because int has no
> method m)
> -
>

You are right. I don't think the foundational argument is touched by that,
as the type set is only smaller because it is shrunken down by methods,
which are considered separately (interface types with method sets can't
appear in unions).

Or maybe it is. TBQH, I did quite a lot of thinking about this topic a
while back (when type sets where first proposed) and I was kind of hoping
to be done with all of that. In fact, this is the first time I really tried
reading the new parts of the spec and I feel re-affirmed in my belief that
the effort we have to go through (both in terms of the room it takes up in
the spec and the amount of effort we invest in trying to figure out if what
we are doing is right) just to make operators work is not really
commensurate with the benefit.


> --
> 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/c511e7f6-2ce3-4c69-af9c-50da95571837n%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfGSQWxpdWg21vMdcaRPLMvPB2jX2OHdXAgc0r0VSArLyg%40mail.gmail.com.

Re: [go-nuts] Re: An mistake in tip spec?

[Brian Candler]

On Thursday, 6 January 2022 at 18:52:30 UTC axel.wa...@googlemail.com wrote:

> The actual type set is hard to compute, in general 
> , so 
> using it to define the set of allowed operations on a type is impractical. 
> The easier to calculate set of specific types was introduced, I believe, to 
> fix this problem. It should always be a subset of the actual type set.
>

 Is that necessarily true? The spec appears to have an example where the 
specific types are a superset of the type set:

-
Examples of interfaces with their specific types:
...
interface{ int; m() } // int (but type set is empty because int has no 
method m)
-

-- 
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/c511e7f6-2ce3-4c69-af9c-50da95571837n%40googlegroups.com.

Re: [go-nuts] Re: An mistake in tip spec?

[Ian Lance Taylor]

On Thu, Jan 6, 2022 at 11:32 AM Axel Wagner
 wrote:
>
> On Thu, Jan 6, 2022 at 8:18 PM Ian Lance Taylor  wrote:
>>
>> On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts
>>  wrote:
>> >
>> > • From the definition of type elements, we can see that an embedded 
>> > interface type is a type element. Therefore, `any` is a type element.
>> > • `any` is an alias for `interface{}`, therefore it is a type without any 
>> > type elements, therefore the set of its specific types is empty ("For an 
>> > interface with no type elements, 𝑆 is the empty set.").
>> > • `interface{ int; any }` is a type with two type elements. "For an 
>> > interface with type elements, 𝑆 is the intersection of the specific types 
>> > of its type elements.". Intersecting with an empty set (the specific types 
>> > of `any`) gives an empty set
>> > • Therefore, the set of specific types of `interface{ int; any }` is the 
>> > empty set.
>>
>> That doesn't seem right.  "any" is an interface type and writing
>> "interface { any }" just embeds the empty interface, which has no
>> effect.
>
>
> I think it has no effect on the type set. But it has an effect on the set of 
> specific types.
>
> I believe both the rule "for an interface type without type elements S is 
> empty" and the rule "for an interface type with type elements, S is the 
> intersection of the specific types of its type elements" are vital to the 
> working of S - they are, what makes the set easily computable.
>
> To answer the question from your comment in the CL: I believe the grammar is 
> very unambiguous about `any` being a type element:
>
>> InterfaceType = "interface" "{" { InterfaceElem ";" } "}" .
>> InterfaceElem = MethodElem | TypeElem .
>> MethodElem = MethodName Signature .
>> MethodName = identifier .
>> TypeElem = TypeTerm { "|" TypeTerm } .
>> TypeTerm = Type | UnderlyingType .
>> UnderlyingType = "~" Type .
>
>
> There is no signature, so it's not a MethodElem. Therefore it must be a 
> TypeElem.

Yeah, I think there is something wrong in the current spec.  It can't
be the case that embedding an interface eliminates all specific types.

Ian

-- 
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/CAOyqgcUi3N7n-jXUHfRfZ%2B%2BtZvd4g_Mb0iZVgS1v_Y316x-sAw%40mail.gmail.com.

Re: [go-nuts] Re: An mistake in tip spec?

['Axel Wagner' via golang-nuts]

On Thu, Jan 6, 2022 at 8:18 PM Ian Lance Taylor  wrote:

> On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts
>  wrote:
> >
> > • From the definition of type elements, we can see that an embedded
> interface type is a type element. Therefore, `any` is a type element.
> > • `any` is an alias for `interface{}`, therefore it is a type without
> any type elements, therefore the set of its specific types is empty ("For
> an interface with no type elements, 𝑆 is the empty set.").
> > • `interface{ int; any }` is a type with two type elements. "For an
> interface with type elements, 𝑆 is the intersection of the specific types
> of its type elements.". Intersecting with an empty set (the specific types
> of `any`) gives an empty set
> > • Therefore, the set of specific types of `interface{ int; any }` is the
> empty set.
>
> That doesn't seem right.  "any" is an interface type and writing
> "interface { any }" just embeds the empty interface, which has no
> effect.
>

I think it has no effect on the type set. But it has an effect on the set
of specific types.

I believe both the rule "for an interface type without type elements S is
empty" and the rule "for an interface type with type elements, S is the
intersection of the specific types of its type elements" are vital to the
working of S - they are, what makes the set easily computable.

To answer the question from your comment in the CL: I believe the grammar
 is very unambiguous about
`any` being a type element:

InterfaceType = "interface" "{" { InterfaceElem ";" } "}" .
> InterfaceElem = MethodElem | TypeElem .
> MethodElem = MethodName Signature .
> MethodName = identifier .
> TypeElem = TypeTerm { "|" TypeTerm } .
> TypeTerm = Type | UnderlyingType .
> UnderlyingType = "~" Type .


There is no signature, so it's not a MethodElem. Therefore it must be a
TypeElem.


> I think the spec is incorrect here (and gri already sent
> https://golang.org/cl/375799 for this).
>
> But maybe there is something else wrong with the description of specific
> types.
>
> Ian
>
>
> > On Thu, Jan 6, 2022 at 5:34 PM Jason Phillips <
> jasonryanphill...@gmail.com> wrote:
> >>
> >> And by "first paragraph of the spec" I mean "first paragraph of the
> Structure of interfaces section of the spec". Apologies.
> >>
> >> On Thursday, January 6, 2022 at 11:11:45 AM UTC-5 Jason Phillips wrote:
> >>>
> >>> @Brian
> >>>
> >>> > interface{ int; m() } // [specific type] int (but type set is empty
> because int has no method m)
> >>> > interface{ int; any } // no specific types (intersection is empty)
> [even though the type set is not empty]
> >>>
> >>> As noted in the first paragraph of the spec, the set of specific types
> is calculated by only considering type elements in the interface. Given
> that, I think the spec note is wrong in the example being discussed. It
> should be "int". Also, regardless of the answer, surely the specific types
> for "interface{ int; m() }" and "interface{ int; any}" are always the same?
> >>>
> >>> On Thursday, January 6, 2022 at 10:37:55 AM UTC-5 tapi...@gmail.com
> wrote:
> 
>  On Thursday, January 6, 2022 at 11:19:40 PM UTC+8 tapi...@gmail.com
> wrote:
> >
> > On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com
> wrote:
> >>
> >> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler
> wrote:
> >>>
> >>> No, the mistake is in your reading of the spec.  You are
> complaining about this line:
> >>>
> >>> interface{ int; any } // no specific types (intersection is empty)
> >>>
> >>> The spec makes it clear that:
> >>> 1. "any" is short for "interface {}"
> >>> 2. "interface {}" has no specific types
> >>>
> >>
> >> I think your logic mistake here is that the operands of the union
> and intersection operations are type sets, instead of specific types.
> >
> >
> > This conclusion is not very precise. More precisely, the operands of
> the union and intersection operations
> > could be either type set or specific types, but interface types
> don't participate in calculations of specific types.
> 
> 
>  This is still not precise. More precisely speaking, in calculations
> of specific types,
>  interface types don't participate in intersection operations,
>  and only "any" (interface{}) is allowed to participate in union
> operations.
>  The result of a union operation with any as an operand is a blank set.
> 
> >
> >
> >>
> >>
> >>>
> >>> You are taking the intersection of the set of one type (int) with
> the empty set, and therefore the result is the empty set.  Exactly as the
> comment says.
> >>>
> >>> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com
> wrote:
> 
>  On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler
> wrote:
> >
> > 1. interface { a;b } is intersection. The "Intersect

Re: [go-nuts] Re: An mistake in tip spec?

[Ian Lance Taylor]

On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts
 wrote:
>
> • From the definition of type elements, we can see that an embedded interface 
> type is a type element. Therefore, `any` is a type element.
> • `any` is an alias for `interface{}`, therefore it is a type without any 
> type elements, therefore the set of its specific types is empty ("For an 
> interface with no type elements, 𝑆 is the empty set.").
> • `interface{ int; any }` is a type with two type elements. "For an interface 
> with type elements, 𝑆 is the intersection of the specific types of its type 
> elements.". Intersecting with an empty set (the specific types of `any`) 
> gives an empty set
> • Therefore, the set of specific types of `interface{ int; any }` is the 
> empty set.

That doesn't seem right.  "any" is an interface type and writing
"interface { any }" just embeds the empty interface, which has no
effect.

I think the spec is incorrect here (and gri already sent
https://golang.org/cl/375799 for this).

But maybe there is something else wrong with the description of specific types.

Ian


> On Thu, Jan 6, 2022 at 5:34 PM Jason Phillips  
> wrote:
>>
>> And by "first paragraph of the spec" I mean "first paragraph of the 
>> Structure of interfaces section of the spec". Apologies.
>>
>> On Thursday, January 6, 2022 at 11:11:45 AM UTC-5 Jason Phillips wrote:
>>>
>>> @Brian
>>>
>>> > interface{ int; m() } // [specific type] int (but type set is empty 
>>> > because int has no method m)
>>> > interface{ int; any } // no specific types (intersection is empty) [even 
>>> > though the type set is not empty]
>>>
>>> As noted in the first paragraph of the spec, the set of specific types is 
>>> calculated by only considering type elements in the interface. Given that, 
>>> I think the spec note is wrong in the example being discussed. It should be 
>>> "int". Also, regardless of the answer, surely the specific types for 
>>> "interface{ int; m() }" and "interface{ int; any}" are always the same?
>>>
>>> On Thursday, January 6, 2022 at 10:37:55 AM UTC-5 tapi...@gmail.com wrote:

 On Thursday, January 6, 2022 at 11:19:40 PM UTC+8 tapi...@gmail.com wrote:
>
> On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com wrote:
>>
>> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:
>>>
>>> No, the mistake is in your reading of the spec.  You are complaining 
>>> about this line:
>>>
>>> interface{ int; any } // no specific types (intersection is empty)
>>>
>>> The spec makes it clear that:
>>> 1. "any" is short for "interface {}"
>>> 2. "interface {}" has no specific types
>>>
>>
>> I think your logic mistake here is that the operands of the union and 
>> intersection operations are type sets, instead of specific types.
>
>
> This conclusion is not very precise. More precisely, the operands of the 
> union and intersection operations
> could be either type set or specific types, but interface types don't 
> participate in calculations of specific types.


 This is still not precise. More precisely speaking, in calculations of 
 specific types,
 interface types don't participate in intersection operations,
 and only "any" (interface{}) is allowed to participate in union operations.
 The result of a union operation with any as an operand is a blank set.

>
>
>>
>>
>>>
>>> You are taking the intersection of the set of one type (int) with the 
>>> empty set, and therefore the result is the empty set.  Exactly as the 
>>> comment says.
>>>
>>> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:

 On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>
> 1. interface { a;b } is intersection. The "Intersection" between two 
> sets means things which exist in both sets simultaneously.
> 2. interface { a|b } is union.  "Union" means a set of things which 
> which exist in set A or set B.
>
> Quoting from the spec:
> "the predeclared type any is an alias for the empty interface."
> "interface{} // no specific types"
> "For an interface with type elements, 𝑆 is the intersection of the 
> specific types of its type elements."
>
> Can you see now?


 The explanation is as what I think.
 But what is your conclusion? Is it a mistake in spec?
>>
>> --
>> 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/cda21095-d57e-4f9d-8853-4a6a7e683953n%40googlegroups.com.
>
> --
> You received this message beca

Re: [go-nuts] Re: An mistake in tip spec?

['Axel Wagner' via golang-nuts]

To elaborate a bit about the differences between "the type set" and "the
set of specific types" and the purpose of the latter - at least as I
understand it:

The actual type set is hard to compute, in general
, so
using it to define the set of allowed operations on a type is impractical.
The easier to calculate set of specific types was introduced, I believe, to
fix this problem. It should always be a subset of the actual type set. By
being easy to compute, it is useful to determine what operations are
allowed on a type parameter in a function body - we can calculate the set
of specific types and just verify that an operation is allowed on all of
them. As it's a subset of the true type set, this will never allow an
operation, which is not allowed by all elements in the type set. But it
might disallow operations, which the type set would allow.

OTOH, checking if any given type is an element of the type set is easy. So
the type set is still useful to determine if a function can be
*instantiated* using a given type - as in that case, the type is known and
we just need to verify it's in the type set.

In short: The type set is used to validate instantiations of a generic
function, while the set of specific types is used to validate the body of a
generic function.

In this case, the set of specific types is smaller, than the actual type
set. The type set is `{int}`, but the set of specific types is empty.
Therefore, the function should be able to be instantiated with `int`, but
the function body should not be allowed to do any operation on the type
parameter (which is not allowed by all types). Which is why I'm inclined to
believe that the compiler is wrong here - if we think this should work, we
probably shouldn't have the set of specific types to begin with.

It may seem unfortunate to end with an empty set of specific types (and
thus empty set of allowed operations), but it's dictated by the
computational difficulty of the problem. And, ultimately, this should only
really carry in cases which are pathological. i.e. the way to solve this
limitation, is to simply not use `interface{ int; any }`, but instead use
`interface { int }`, which has the same type set *and* a non-empty set of
specific types (equal to its type set).

On Thu, Jan 6, 2022 at 7:23 PM Axel Wagner 
wrote:

>
>
> On Thu, Jan 6, 2022 at 7:02 PM Brian Candler  wrote:
>
>> On Thursday, 6 January 2022 at 17:13:38 UTC axel.wa...@googlemail.com
>> wrote:
>>
>>> On Thu, Jan 6, 2022 at 1:58 PM tapi...@gmail.com 
>>> wrote:
>>>
 I don't think your conclusion is right. Otherwise, the following code
 doesn't compile, but it does.

 type C interface{ int; any }

 func f[T C](x byte) T {
 return T(x)
 }

>>>
>>> I agree that the compiler and spec seem to disagree here. It seems to me
>>> that by the spec, this should not be allowed, as C has no specific types.
>>>
>>
>> But is that true?  "Type set" and "specific types" are two different
>> concepts, and "specific types" are only required in certain contexts, which
>> are called out in the spec.
>>
>
> Correct. One of those is determining if the conversion `T(x)` is legal, if
> `T` is a type parameter. Specifically, it only makes it legal if `T` is a
> type parameter with specific types.
>
> It seems that function f[T C] will accept any type which is in the *type
>> set* of C - is that not reasonable?
>>
>
> Yes. But the issue isn't the instantiation of `f` (in fact, `f` is not
> instantiated in this code), it's the definition.
>
>
>>
>> This does of course highlight how complex the language has become with
>> the introduction of generics.
>>
>> --
>> 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/6edaaaf6-87a8-4cb4-9015-8bb007a5d70cn%40googlegroups.com
>> 
>> .
>>
>

-- 
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/CAEkBMfG3ADrXFct0x98BS%3DPyXsp_FxcCLuS-DBKfav_%2B9OHOmg%40mail.gmail.com.

Re: [go-nuts] Re: An mistake in tip spec?

['Axel Wagner' via golang-nuts]

On Thu, Jan 6, 2022 at 7:02 PM Brian Candler  wrote:

> On Thursday, 6 January 2022 at 17:13:38 UTC axel.wa...@googlemail.com
> wrote:
>
>> On Thu, Jan 6, 2022 at 1:58 PM tapi...@gmail.com 
>> wrote:
>>
>>> I don't think your conclusion is right. Otherwise, the following code
>>> doesn't compile, but it does.
>>>
>>> type C interface{ int; any }
>>>
>>> func f[T C](x byte) T {
>>> return T(x)
>>> }
>>>
>>
>> I agree that the compiler and spec seem to disagree here. It seems to me
>> that by the spec, this should not be allowed, as C has no specific types.
>>
>
> But is that true?  "Type set" and "specific types" are two different
> concepts, and "specific types" are only required in certain contexts, which
> are called out in the spec.
>

Correct. One of those is determining if the conversion `T(x)` is legal, if
`T` is a type parameter. Specifically, it only makes it legal if `T` is a
type parameter with specific types.

It seems that function f[T C] will accept any type which is in the *type
> set* of C - is that not reasonable?
>

Yes. But the issue isn't the instantiation of `f` (in fact, `f` is not
instantiated in this code), it's the definition.


>
> This does of course highlight how complex the language has become with the
> introduction of generics.
>
> --
> 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/6edaaaf6-87a8-4cb4-9015-8bb007a5d70cn%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfE11SwkehK4geQiRBY4A-2wnbkMRJy_Wj7_AgFb2jyYvQ%40mail.gmail.com.

Re: [go-nuts] Re: An mistake in tip spec?

[Brian Candler]

On Thursday, 6 January 2022 at 17:13:38 UTC axel.wa...@googlemail.com wrote:

> On Thu, Jan 6, 2022 at 1:58 PM tapi...@gmail.com  
> wrote:
>
>> I don't think your conclusion is right. Otherwise, the following code 
>> doesn't compile, but it does.
>>
>> type C interface{ int; any }
>>
>> func f[T C](x byte) T {
>> return T(x)
>> }
>>
>
> I agree that the compiler and spec seem to disagree here. It seems to me 
> that by the spec, this should not be allowed, as C has no specific types.
>

But is that true?  "Type set" and "specific types" are two different 
concepts, and "specific types" are only required in certain contexts, which 
are called out in the spec.

It seems that function f[T C] will accept any type which is in the *type 
set* of C - is that not reasonable?

This does of course highlight how complex the language has become with the 
introduction of generics.

-- 
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/6edaaaf6-87a8-4cb4-9015-8bb007a5d70cn%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[Jason Phillips]

It does seem like the spec could be more clear for this specific example. 
The type set of "interface{ int; m() }" is called out explicitly so the 
same seems helpful for "interface{ int; any }".

On Thursday, January 6, 2022 at 12:00:47 PM UTC-5 Jason Phillips wrote:

> > But the set of specific types is "int".
> But the *type set* is "int"...
>
> On Thursday, January 6, 2022 at 11:57:59 AM UTC-5 Jason Phillips wrote:
>
>> I take my argument back, I agree with Brian here. According to the spec 
>> "interface{}" is a type element because it contains no methods. So the 
>> intersection of the specific types "interface{}" and "int" is an empty set. 
>> But the set of specific types is "int".
>>
>> On Thursday, January 6, 2022 at 11:34:02 AM UTC-5 Jason Phillips wrote:
>>
>>> And by "first paragraph of the spec" I mean "first paragraph of the 
>>> Structure of interfaces section of the spec". Apologies.
>>>
>>> On Thursday, January 6, 2022 at 11:11:45 AM UTC-5 Jason Phillips wrote:
>>>
 @Brian

 > interface{ int; m() } // *[specific type]* int (but type set is 
 empty because int has no method m)
 > interface{ int; any } // no specific types (intersection is empty) 
 > *[even 
 though the type set is not empty]*

 As noted in the first paragraph of the spec, the set of specific types 
 is calculated by only considering type elements in the interface. Given 
 that, I think the spec note is wrong in the example being discussed. It 
 should be "int". Also, regardless of the answer, surely the specific types 
 for "interface{ int; m() }" and "interface{ int; any}" are always the same?

 On Thursday, January 6, 2022 at 10:37:55 AM UTC-5 tapi...@gmail.com 
 wrote:

> On Thursday, January 6, 2022 at 11:19:40 PM UTC+8 tapi...@gmail.com 
> wrote:
>
>> On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com 
>> wrote:
>>
>>> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:
>>>
 No, the mistake is in your reading of the spec.  You are 
 complaining about this line:

 interface{ int; any } // no specific types (intersection is empty)

 The spec makes it clear that:
 1. "any" is short for "interface {}"
 2. "interface {}" has no *specific types*


>>> I think your logic mistake here is that the operands of the union 
>>> and intersection operations are type sets, instead of specific types.
>>>
>>
>> This conclusion is not very precise. More precisely, the operands of 
>> the union and intersection operations
>> could be either type set or specific types, but interface types don't 
>> participate in calculations of specific types.
>>
>
> This is still not precise. More precisely speaking, in calculations of 
> specific types,
> interface types don't participate in intersection operations,
> and only "any" (interface{}) is allowed to participate in union 
> operations.
> The result of a union operation with any as an operand is a blank set.
>  
>
>>  
>>
>>>  
>>>
 You are taking the intersection of the set of one type (int) with 
 the empty set, and therefore the result is the empty set.  Exactly as 
 the 
 comment says.

 On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com 
 wrote:

> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler 
> wrote:
>
>> 1. interface { a;b } is intersection. The "Intersection" between 
>> two sets means things which exist in both sets simultaneously.
>> 2. interface { a|b } is union.  "Union" means a set of things 
>> which which exist in set A *or* set B.
>>
>> Quoting from the spec:
>> *"the predeclared type *any* is an alias for the empty 
>> interface." *
>> *"interface{} // no specific types"*
>> *"For an interface with type elements, 𝑆 is the intersection of 
>> the specific types of its type elements."*
>>
>> Can you see now?
>>
>
> The explanation is as what I think.
> But what is your conclusion? Is it a mistake in spec?
>


-- 
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/29c15882-63e8-4bb9-baf1-12c999583479n%40googlegroups.com.

Re: [go-nuts] Re: An mistake in tip spec?

['Axel Wagner' via golang-nuts]

On Thu, Jan 6, 2022 at 1:58 PM tapi...@gmail.com 
wrote:

> I don't think your conclusion is right. Otherwise, the following code
> doesn't compile, but it does.
>
> type C interface{ int; any }
>
> func f[T C](x byte) T {
> return T(x)
> }
>

I agree that the compiler and spec seem to disagree here. It seems to me
that by the spec, this should not be allowed, as C has no specific types.
Note that this doesn't mean the spec is wrong - it can also mean the
compiler is wrong.


>
> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:
>
>> No, the mistake is in your reading of the spec.  You are complaining
>> about this line:
>>
>> interface{ int; any } // no specific types (intersection is empty)
>>
>> The spec makes it clear that:
>> 1. "any" is short for "interface {}"
>> 2. "interface {}" has no *specific types*
>> 3. "interface { int; any }" is an *intersection* of *specific types*
>>
>> You are taking the intersection of the set of one type (int) with the
>> empty set, and therefore the result is the empty set.  Exactly as the
>> comment says.
>>
>> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>>
>>> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>>>
 1. interface { a;b } is intersection. The "Intersection" between two
 sets means things which exist in both sets simultaneously.
 2. interface { a|b } is union.  "Union" means a set of things which
 which exist in set A *or* set B.

 Quoting from the spec:
 *"the predeclared type *any* is an alias for the empty interface." *
 *"interface{} // no specific types"*
 *"For an interface with type elements, 𝑆 is the intersection of the
 specific types of its type elements."*

 Can you see now?

>>>
>>> The explanation is as what I think.
>>> But what is your conclusion? Is it a mistake in spec?
>>>
>> --
> 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/e43a60ad-d812-418d-97e1-966fd3bcf61en%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfGtMPq0OPd%2BnSz7Hok_T_tCH1f1Axo1dqn2eezKH0LhJA%40mail.gmail.com.

[go-nuts] Re: An mistake in tip spec?

[Jason Phillips]

> But the set of specific types is "int".
But the *type set* is "int"...

On Thursday, January 6, 2022 at 11:57:59 AM UTC-5 Jason Phillips wrote:

> I take my argument back, I agree with Brian here. According to the spec 
> "interface{}" is a type element because it contains no methods. So the 
> intersection of the specific types "interface{}" and "int" is an empty set. 
> But the set of specific types is "int".
>
> On Thursday, January 6, 2022 at 11:34:02 AM UTC-5 Jason Phillips wrote:
>
>> And by "first paragraph of the spec" I mean "first paragraph of the 
>> Structure of interfaces section of the spec". Apologies.
>>
>> On Thursday, January 6, 2022 at 11:11:45 AM UTC-5 Jason Phillips wrote:
>>
>>> @Brian
>>>
>>> > interface{ int; m() } // *[specific type]* int (but type set is empty 
>>> because int has no method m)
>>> > interface{ int; any } // no specific types (intersection is empty) *[even 
>>> though the type set is not empty]*
>>>
>>> As noted in the first paragraph of the spec, the set of specific types 
>>> is calculated by only considering type elements in the interface. Given 
>>> that, I think the spec note is wrong in the example being discussed. It 
>>> should be "int". Also, regardless of the answer, surely the specific types 
>>> for "interface{ int; m() }" and "interface{ int; any}" are always the same?
>>>
>>> On Thursday, January 6, 2022 at 10:37:55 AM UTC-5 tapi...@gmail.com 
>>> wrote:
>>>
 On Thursday, January 6, 2022 at 11:19:40 PM UTC+8 tapi...@gmail.com 
 wrote:

> On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com 
> wrote:
>
>> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:
>>
>>> No, the mistake is in your reading of the spec.  You are complaining 
>>> about this line:
>>>
>>> interface{ int; any } // no specific types (intersection is empty)
>>>
>>> The spec makes it clear that:
>>> 1. "any" is short for "interface {}"
>>> 2. "interface {}" has no *specific types*
>>>
>>>
>> I think your logic mistake here is that the operands of the union and 
>> intersection operations are type sets, instead of specific types.
>>
>
> This conclusion is not very precise. More precisely, the operands of 
> the union and intersection operations
> could be either type set or specific types, but interface types don't 
> participate in calculations of specific types.
>

 This is still not precise. More precisely speaking, in calculations of 
 specific types,
 interface types don't participate in intersection operations,
 and only "any" (interface{}) is allowed to participate in union 
 operations.
 The result of a union operation with any as an operand is a blank set.
  

>  
>
>>  
>>
>>> You are taking the intersection of the set of one type (int) with 
>>> the empty set, and therefore the result is the empty set.  Exactly as 
>>> the 
>>> comment says.
>>>
>>> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>>>
 On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler 
 wrote:

> 1. interface { a;b } is intersection. The "Intersection" between 
> two sets means things which exist in both sets simultaneously.
> 2. interface { a|b } is union.  "Union" means a set of things 
> which which exist in set A *or* set B.
>
> Quoting from the spec:
> *"the predeclared type *any* is an alias for the empty 
> interface." *
> *"interface{} // no specific types"*
> *"For an interface with type elements, 𝑆 is the intersection of 
> the specific types of its type elements."*
>
> Can you see now?
>

 The explanation is as what I think.
 But what is your conclusion? Is it a mistake in spec?

>>>

-- 
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/20d52201-662a-4efb-8fde-a9355ec6414bn%40googlegroups.com.

Re: [go-nuts] Re: An mistake in tip spec?

['Axel Wagner' via golang-nuts]

• From the definition of type elements
, we can see that an
embedded interface type is a type element. Therefore, `any` is a type
element.
• `any` is an alias for `interface{}`, therefore it is a type without any
type elements, therefore the set of its specific types is empty ("For an
interface with no type elements, 𝑆 is the empty set.").
• `interface{ int; any }` is a type with two type elements. "For an
interface with type elements, 𝑆 is the intersection of the specific types
of its type elements.". Intersecting with an empty set (the specific types
of `any`) gives an empty set
• Therefore, the set of specific types of `interface{ int; any }` is the
empty set.

On Thu, Jan 6, 2022 at 5:34 PM Jason Phillips 
wrote:

> And by "first paragraph of the spec" I mean "first paragraph of the
> Structure of interfaces section of the spec". Apologies.
>
> On Thursday, January 6, 2022 at 11:11:45 AM UTC-5 Jason Phillips wrote:
>
>> @Brian
>>
>> > interface{ int; m() } // *[specific type]* int (but type set is empty
>> because int has no method m)
>> > interface{ int; any } // no specific types (intersection is empty) *[even
>> though the type set is not empty]*
>>
>> As noted in the first paragraph of the spec, the set of specific types is
>> calculated by only considering type elements in the interface. Given that,
>> I think the spec note is wrong in the example being discussed. It should be
>> "int". Also, regardless of the answer, surely the specific types for
>> "interface{ int; m() }" and "interface{ int; any}" are always the same?
>>
>> On Thursday, January 6, 2022 at 10:37:55 AM UTC-5 tapi...@gmail.com
>> wrote:
>>
>>> On Thursday, January 6, 2022 at 11:19:40 PM UTC+8 tapi...@gmail.com
>>> wrote:
>>>
 On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com
 wrote:

> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:
>
>> No, the mistake is in your reading of the spec.  You are complaining
>> about this line:
>>
>> interface{ int; any } // no specific types (intersection is empty)
>>
>> The spec makes it clear that:
>> 1. "any" is short for "interface {}"
>> 2. "interface {}" has no *specific types*
>>
>>
> I think your logic mistake here is that the operands of the union and
> intersection operations are type sets, instead of specific types.
>

 This conclusion is not very precise. More precisely, the operands of
 the union and intersection operations
 could be either type set or specific types, but interface types don't
 participate in calculations of specific types.

>>>
>>> This is still not precise. More precisely speaking, in calculations of
>>> specific types,
>>> interface types don't participate in intersection operations,
>>> and only "any" (interface{}) is allowed to participate in union
>>> operations.
>>> The result of a union operation with any as an operand is a blank set.
>>>
>>>


>
>
>> You are taking the intersection of the set of one type (int) with the
>> empty set, and therefore the result is the empty set.  Exactly as the
>> comment says.
>>
>> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>>
>>> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>>>
 1. interface { a;b } is intersection. The "Intersection" between
 two sets means things which exist in both sets simultaneously.
 2. interface { a|b } is union.  "Union" means a set of things which
 which exist in set A *or* set B.

 Quoting from the spec:
 *"the predeclared type *any* is an alias for the empty
 interface." *
 *"interface{} // no specific types"*
 *"For an interface with type elements, 𝑆 is the intersection of
 the specific types of its type elements."*

 Can you see now?

>>>
>>> The explanation is as what I think.
>>> But what is your conclusion? Is it a mistake in spec?
>>>
>> --
> 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/cda21095-d57e-4f9d-8853-4a6a7e683953n%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfGV9tfn%2BZfRKs%3Dy

[go-nuts] Re: An mistake in tip spec?

[Jason Phillips]

I take my argument back, I agree with Brian here. According to the spec 
"interface{}" is a type element because it contains no methods. So the 
intersection of the specific types "interface{}" and "int" is an empty set. 
But the set of specific types is "int".

On Thursday, January 6, 2022 at 11:34:02 AM UTC-5 Jason Phillips wrote:

> And by "first paragraph of the spec" I mean "first paragraph of the 
> Structure of interfaces section of the spec". Apologies.
>
> On Thursday, January 6, 2022 at 11:11:45 AM UTC-5 Jason Phillips wrote:
>
>> @Brian
>>
>> > interface{ int; m() } // *[specific type]* int (but type set is empty 
>> because int has no method m)
>> > interface{ int; any } // no specific types (intersection is empty) *[even 
>> though the type set is not empty]*
>>
>> As noted in the first paragraph of the spec, the set of specific types is 
>> calculated by only considering type elements in the interface. Given that, 
>> I think the spec note is wrong in the example being discussed. It should be 
>> "int". Also, regardless of the answer, surely the specific types for 
>> "interface{ int; m() }" and "interface{ int; any}" are always the same?
>>
>> On Thursday, January 6, 2022 at 10:37:55 AM UTC-5 tapi...@gmail.com 
>> wrote:
>>
>>> On Thursday, January 6, 2022 at 11:19:40 PM UTC+8 tapi...@gmail.com 
>>> wrote:
>>>
 On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com 
 wrote:

> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:
>
>> No, the mistake is in your reading of the spec.  You are complaining 
>> about this line:
>>
>> interface{ int; any } // no specific types (intersection is empty)
>>
>> The spec makes it clear that:
>> 1. "any" is short for "interface {}"
>> 2. "interface {}" has no *specific types*
>>
>>
> I think your logic mistake here is that the operands of the union and 
> intersection operations are type sets, instead of specific types.
>

 This conclusion is not very precise. More precisely, the operands of 
 the union and intersection operations
 could be either type set or specific types, but interface types don't 
 participate in calculations of specific types.

>>>
>>> This is still not precise. More precisely speaking, in calculations of 
>>> specific types,
>>> interface types don't participate in intersection operations,
>>> and only "any" (interface{}) is allowed to participate in union 
>>> operations.
>>> The result of a union operation with any as an operand is a blank set.
>>>  
>>>
  

>  
>
>> You are taking the intersection of the set of one type (int) with the 
>> empty set, and therefore the result is the empty set.  Exactly as the 
>> comment says.
>>
>> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>>
>>> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>>>
 1. interface { a;b } is intersection. The "Intersection" between 
 two sets means things which exist in both sets simultaneously.
 2. interface { a|b } is union.  "Union" means a set of things which 
 which exist in set A *or* set B.

 Quoting from the spec:
 *"the predeclared type *any* is an alias for the empty 
 interface." *
 *"interface{} // no specific types"*
 *"For an interface with type elements, 𝑆 is the intersection of 
 the specific types of its type elements."*

 Can you see now?

>>>
>>> The explanation is as what I think.
>>> But what is your conclusion? Is it a mistake in spec?
>>>
>>

-- 
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/531b392e-fcb8-4b90-8bf6-51202e5af5dan%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[Jason Phillips]

And by "first paragraph of the spec" I mean "first paragraph of the 
Structure of interfaces section of the spec". Apologies.

On Thursday, January 6, 2022 at 11:11:45 AM UTC-5 Jason Phillips wrote:

> @Brian
>
> > interface{ int; m() } // *[specific type]* int (but type set is empty 
> because int has no method m)
> > interface{ int; any } // no specific types (intersection is empty) *[even 
> though the type set is not empty]*
>
> As noted in the first paragraph of the spec, the set of specific types is 
> calculated by only considering type elements in the interface. Given that, 
> I think the spec note is wrong in the example being discussed. It should be 
> "int". Also, regardless of the answer, surely the specific types for 
> "interface{ int; m() }" and "interface{ int; any}" are always the same?
>
> On Thursday, January 6, 2022 at 10:37:55 AM UTC-5 tapi...@gmail.com wrote:
>
>> On Thursday, January 6, 2022 at 11:19:40 PM UTC+8 tapi...@gmail.com 
>> wrote:
>>
>>> On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com 
>>> wrote:
>>>
 On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:

> No, the mistake is in your reading of the spec.  You are complaining 
> about this line:
>
> interface{ int; any } // no specific types (intersection is empty)
>
> The spec makes it clear that:
> 1. "any" is short for "interface {}"
> 2. "interface {}" has no *specific types*
>
>
 I think your logic mistake here is that the operands of the union and 
 intersection operations are type sets, instead of specific types.

>>>
>>> This conclusion is not very precise. More precisely, the operands of the 
>>> union and intersection operations
>>> could be either type set or specific types, but interface types don't 
>>> participate in calculations of specific types.
>>>
>>
>> This is still not precise. More precisely speaking, in calculations of 
>> specific types,
>> interface types don't participate in intersection operations,
>> and only "any" (interface{}) is allowed to participate in union 
>> operations.
>> The result of a union operation with any as an operand is a blank set.
>>  
>>
>>>  
>>>
  

> You are taking the intersection of the set of one type (int) with the 
> empty set, and therefore the result is the empty set.  Exactly as the 
> comment says.
>
> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>
>> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>>
>>> 1. interface { a;b } is intersection. The "Intersection" between two 
>>> sets means things which exist in both sets simultaneously.
>>> 2. interface { a|b } is union.  "Union" means a set of things which 
>>> which exist in set A *or* set B.
>>>
>>> Quoting from the spec:
>>> *"the predeclared type *any* is an alias for the empty interface." *
>>> *"interface{} // no specific types"*
>>> *"For an interface with type elements, 𝑆 is the intersection of the 
>>> specific types of its type elements."*
>>>
>>> Can you see now?
>>>
>>
>> The explanation is as what I think.
>> But what is your conclusion? Is it a mistake in spec?
>>
>

-- 
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/cda21095-d57e-4f9d-8853-4a6a7e683953n%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[Jason Phillips]

@Brian

> interface{ int; m() } // *[specific type]* int (but type set is empty 
because int has no method m)
> interface{ int; any } // no specific types (intersection is empty) *[even 
though the type set is not empty]*

As noted in the first paragraph of the spec, the set of specific types is 
calculated by only considering type elements in the interface. Given that, 
I think the spec note is wrong in the example being discussed. It should be 
"int". Also, regardless of the answer, surely the specific types for 
"interface{ int; m() }" and "interface{ int; any}" are always the same?

On Thursday, January 6, 2022 at 10:37:55 AM UTC-5 tapi...@gmail.com wrote:

> On Thursday, January 6, 2022 at 11:19:40 PM UTC+8 tapi...@gmail.com wrote:
>
>> On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com wrote:
>>
>>> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:
>>>
 No, the mistake is in your reading of the spec.  You are complaining 
 about this line:

 interface{ int; any } // no specific types (intersection is empty)

 The spec makes it clear that:
 1. "any" is short for "interface {}"
 2. "interface {}" has no *specific types*


>>> I think your logic mistake here is that the operands of the union and 
>>> intersection operations are type sets, instead of specific types.
>>>
>>
>> This conclusion is not very precise. More precisely, the operands of the 
>> union and intersection operations
>> could be either type set or specific types, but interface types don't 
>> participate in calculations of specific types.
>>
>
> This is still not precise. More precisely speaking, in calculations of 
> specific types,
> interface types don't participate in intersection operations,
> and only "any" (interface{}) is allowed to participate in union operations.
> The result of a union operation with any as an operand is a blank set.
>  
>
>>  
>>
>>>  
>>>
 You are taking the intersection of the set of one type (int) with the 
 empty set, and therefore the result is the empty set.  Exactly as the 
 comment says.

 On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:

> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>
>> 1. interface { a;b } is intersection. The "Intersection" between two 
>> sets means things which exist in both sets simultaneously.
>> 2. interface { a|b } is union.  "Union" means a set of things which 
>> which exist in set A *or* set B.
>>
>> Quoting from the spec:
>> *"the predeclared type *any* is an alias for the empty interface." *
>> *"interface{} // no specific types"*
>> *"For an interface with type elements, 𝑆 is the intersection of the 
>> specific types of its type elements."*
>>
>> Can you see now?
>>
>
> The explanation is as what I think.
> But what is your conclusion? Is it a mistake in spec?
>


-- 
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/bd5b6350-dbbf-4468-b648-f4b497c856ccn%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[tapi...@gmail.com]

On Thursday, January 6, 2022 at 11:19:40 PM UTC+8 tapi...@gmail.com wrote:

> On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com wrote:
>
>> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:
>>
>>> No, the mistake is in your reading of the spec.  You are complaining 
>>> about this line:
>>>
>>> interface{ int; any } // no specific types (intersection is empty)
>>>
>>> The spec makes it clear that:
>>> 1. "any" is short for "interface {}"
>>> 2. "interface {}" has no *specific types*
>>>
>>>
>> I think your logic mistake here is that the operands of the union and 
>> intersection operations are type sets, instead of specific types.
>>
>
> This conclusion is not very precise. More precisely, the operands of the 
> union and intersection operations
> could be either type set or specific types, but interface types don't 
> participate in calculations of specific types.
>

This is still not precise. More precisely speaking, in calculations of 
specific types,
interface types don't participate in intersection operations,
and only "any" (interface{}) is allowed to participate in union operations.
The result of a union operation with any as an operand is a blank set.
 

>  
>
>>  
>>
>>> You are taking the intersection of the set of one type (int) with the 
>>> empty set, and therefore the result is the empty set.  Exactly as the 
>>> comment says.
>>>
>>> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>>>
 On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:

> 1. interface { a;b } is intersection. The "Intersection" between two 
> sets means things which exist in both sets simultaneously.
> 2. interface { a|b } is union.  "Union" means a set of things which 
> which exist in set A *or* set B.
>
> Quoting from the spec:
> *"the predeclared type *any* is an alias for the empty interface." *
> *"interface{} // no specific types"*
> *"For an interface with type elements, 𝑆 is the intersection of the 
> specific types of its type elements."*
>
> Can you see now?
>

 The explanation is as what I think.
 But what is your conclusion? Is it a mistake in spec?

>>>

-- 
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/1795770f-27d4-41fe-b02f-74f2e43d6528n%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[tapi...@gmail.com]

On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com wrote:

> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:
>
>> No, the mistake is in your reading of the spec.  You are complaining 
>> about this line:
>>
>> interface{ int; any } // no specific types (intersection is empty)
>>
>> The spec makes it clear that:
>> 1. "any" is short for "interface {}"
>> 2. "interface {}" has no *specific types*
>>
>>
> I think your logic mistake here is that the operands of the union and 
> intersection operations are type sets, instead of specific types.
>

This conclusion is not very precise. More precisely, the operands of the 
union and intersection operations
could be either type set or specific types, but interface types don't 
participate in calculations of specific types.
 

>  
>
>> You are taking the intersection of the set of one type (int) with the 
>> empty set, and therefore the result is the empty set.  Exactly as the 
>> comment says.
>>
>> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>>
>>> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>>>
 1. interface { a;b } is intersection. The "Intersection" between two 
 sets means things which exist in both sets simultaneously.
 2. interface { a|b } is union.  "Union" means a set of things which 
 which exist in set A *or* set B.

 Quoting from the spec:
 *"the predeclared type *any* is an alias for the empty interface." *
 *"interface{} // no specific types"*
 *"For an interface with type elements, 𝑆 is the intersection of the 
 specific types of its type elements."*

 Can you see now?

>>>
>>> The explanation is as what I think.
>>> But what is your conclusion? Is it a mistake in spec?
>>>
>>

-- 
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/a44f0c52-dde5-4d86-b9e7-7fa097a1dfden%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[tapi...@gmail.com]

sorry again. It should be "the type set and specific types of interface{ 
int; any } are both {int}."

On Thursday, January 6, 2022 at 9:45:35 PM UTC+8 tapi...@gmail.com wrote:

> On Thursday, January 6, 2022 at 9:44:05 PM UTC+8 tapi...@gmail.com wrote:
>
>> On Thursday, January 6, 2022 at 9:40:49 PM UTC+8 Brian Candler wrote:
>>
>>> So to be more specific, I think you're asking why this code works:
>>> https://gotipplay.golang.org/p/kuYzzx4EJY1
>>>
>>> Sorry, I made a mistake in interpreting the spec.  It also says:
>>>
>>> "The type set of the empty interface is the set of all types."
>>>
>>> Therefore, the type set of the intersection { int; any } is int - and 
>>> hence f[int] is allowed.
>>>
>>> But the set of specific types 
>>>  is empty:
>>>
>>> "An interface specification which contains type elements 
>>>  defines a (possibly 
>>> empty) set of *specific types*. Loosely speaking, these are the 
>>> types T that appear in the interface definition in terms of the form T, ~T, 
>>> or in unions of such terms."
>>>
>>> The type set and the set of specific types can be different. Examples 
>>> are given where one is empty and the other is non-empty:
>>>
>>> interface{ int; m() } // *[specific type]* int (but type set is empty 
>>> because int has no method m)
>>> interface{ int; any } // no specific types (intersection is empty) *[even 
>>> though the type set is not empty]*
>>>
>>> *Items in [italics/brackets] are my additions*
>>>
>>
>> > The type set and the set of specific types can be different
>>
>> This is true.
>>
>> > interface{ int; any } // no specific types (intersection is empty) *[even 
>> though the type set is not empty]*
>>
>> I don't think this is true. In my opinion, the method set of specific 
>> types of interface{ int; any } are both {int}.
>>
>
> sorry a typo:  it should be  
>
> the method set and specific types of interface{ int; any } are both {int}.
>

-- 
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/d25a0a6f-95f7-4d04-9321-486789d02339n%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[tapi...@gmail.com]

On Thursday, January 6, 2022 at 9:44:05 PM UTC+8 tapi...@gmail.com wrote:

> On Thursday, January 6, 2022 at 9:40:49 PM UTC+8 Brian Candler wrote:
>
>> So to be more specific, I think you're asking why this code works:
>> https://gotipplay.golang.org/p/kuYzzx4EJY1
>>
>> Sorry, I made a mistake in interpreting the spec.  It also says:
>>
>> "The type set of the empty interface is the set of all types."
>>
>> Therefore, the type set of the intersection { int; any } is int - and 
>> hence f[int] is allowed.
>>
>> But the set of specific types 
>>  is empty:
>>
>> "An interface specification which contains type elements 
>>  defines a (possibly 
>> empty) set of *specific types*. Loosely speaking, these are the 
>> types T that appear in the interface definition in terms of the form T, ~T, 
>> or in unions of such terms."
>>
>> The type set and the set of specific types can be different. Examples are 
>> given where one is empty and the other is non-empty:
>>
>> interface{ int; m() } // *[specific type]* int (but type set is empty 
>> because int has no method m)
>> interface{ int; any } // no specific types (intersection is empty) *[even 
>> though the type set is not empty]*
>>
>> *Items in [italics/brackets] are my additions*
>>
>
> > The type set and the set of specific types can be different
>
> This is true.
>
> > interface{ int; any } // no specific types (intersection is empty) *[even 
> though the type set is not empty]*
>
> I don't think this is true. In my opinion, the method set of specific 
> types of interface{ int; any } are both {int}.
>

sorry a typo:  it should be  

the method set and specific types of interface{ int; any } are both {int}.

-- 
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/24b410b6-879e-4f0b-9156-e6279f3bcb61n%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[tapi...@gmail.com]

On Thursday, January 6, 2022 at 9:40:49 PM UTC+8 Brian Candler wrote:

> So to be more specific, I think you're asking why this code works:
> https://gotipplay.golang.org/p/kuYzzx4EJY1
>
> Sorry, I made a mistake in interpreting the spec.  It also says:
>
> "The type set of the empty interface is the set of all types."
>
> Therefore, the type set of the intersection { int; any } is int - and 
> hence f[int] is allowed.
>
> But the set of specific types 
>  is empty:
>
> "An interface specification which contains type elements 
>  defines a (possibly 
> empty) set of *specific types*. Loosely speaking, these are the 
> types T that appear in the interface definition in terms of the form T, ~T, 
> or in unions of such terms."
>
> The type set and the set of specific types can be different. Examples are 
> given where one is empty and the other is non-empty:
>
> interface{ int; m() } // *[specific type]* int (but type set is empty 
> because int has no method m)
> interface{ int; any } // no specific types (intersection is empty) *[even 
> though the type set is not empty]*
>
> *Items in [italics/brackets] are my additions*
>

> The type set and the set of specific types can be different

This is true.

> interface{ int; any } // no specific types (intersection is empty) *[even 
though the type set is not empty]*

I don't think this is true. In my opinion, the method set of specific types 
of interface{ int; any } are both {int}.

-- 
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/48b67caf-19ae-4ffe-af4d-436268187ef2n%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[tapi...@gmail.com]

On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:

> No, the mistake is in your reading of the spec.  You are complaining about 
> this line:
>
> interface{ int; any } // no specific types (intersection is empty)
>
> The spec makes it clear that:
> 1. "any" is short for "interface {}"
> 2. "interface {}" has no *specific types*
>
>
I think your logic mistake here is that the operands of the union and 
intersection operations are type sets, instead of specific types.
 

> You are taking the intersection of the set of one type (int) with the 
> empty set, and therefore the result is the empty set.  Exactly as the 
> comment says.
>
> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>
>> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>>
>>> 1. interface { a;b } is intersection. The "Intersection" between two 
>>> sets means things which exist in both sets simultaneously.
>>> 2. interface { a|b } is union.  "Union" means a set of things which 
>>> which exist in set A *or* set B.
>>>
>>> Quoting from the spec:
>>> *"the predeclared type *any* is an alias for the empty interface." *
>>> *"interface{} // no specific types"*
>>> *"For an interface with type elements, 𝑆 is the intersection of the 
>>> specific types of its type elements."*
>>>
>>> Can you see now?
>>>
>>
>> The explanation is as what I think.
>> But what is your conclusion? Is it a mistake in spec?
>>
>

-- 
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/856006f6-0624-43e9-b3b8-a07a0d6744a6n%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[Brian Candler]

So to be more specific, I think you're asking why this code works:
https://gotipplay.golang.org/p/kuYzzx4EJY1

Sorry, I made a mistake in interpreting the spec.  It also says:

"The type set of the empty interface is the set of all types."

Therefore, the type set of the intersection { int; any } is int - and hence 
f[int] is allowed.

But the set of specific types 
 is empty:

"An interface specification which contains type elements 
 defines a (possibly 
empty) set of *specific types*. Loosely speaking, these are the 
types T that appear in the interface definition in terms of the form T, ~T, 
or in unions of such terms."

The type set and the set of specific types can be different. Examples are 
given where one is empty and the other is non-empty:

interface{ int; m() } // *[specific type]* int (but type set is empty 
because int has no method m)
interface{ int; any } // no specific types (intersection is empty) *[even 
though the type set is not empty]*

*Items in [italics/brackets] are my additions*

-- 
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/9409fd01-632f-484e-a31e-e19dca080c47n%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[tapi...@gmail.com]

I don't think your conclusion is right. Otherwise, the following code 
doesn't compile, but it does.

type C interface{ int; any }

func f[T C](x byte) T {
return T(x)
}

On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote:

> No, the mistake is in your reading of the spec.  You are complaining about 
> this line:
>
> interface{ int; any } // no specific types (intersection is empty)
>
> The spec makes it clear that:
> 1. "any" is short for "interface {}"
> 2. "interface {}" has no *specific types*
> 3. "interface { int; any }" is an *intersection* of *specific types*
>
> You are taking the intersection of the set of one type (int) with the 
> empty set, and therefore the result is the empty set.  Exactly as the 
> comment says.
>
> On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:
>
>> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>>
>>> 1. interface { a;b } is intersection. The "Intersection" between two 
>>> sets means things which exist in both sets simultaneously.
>>> 2. interface { a|b } is union.  "Union" means a set of things which 
>>> which exist in set A *or* set B.
>>>
>>> Quoting from the spec:
>>> *"the predeclared type *any* is an alias for the empty interface." *
>>> *"interface{} // no specific types"*
>>> *"For an interface with type elements, 𝑆 is the intersection of the 
>>> specific types of its type elements."*
>>>
>>> Can you see now?
>>>
>>
>> The explanation is as what I think.
>> But what is your conclusion? Is it a mistake in spec?
>>
>

-- 
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/e43a60ad-d812-418d-97e1-966fd3bcf61en%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[Brian Candler]

No, the mistake is in your reading of the spec.  You are complaining about 
this line:

interface{ int; any } // no specific types (intersection is empty)

The spec makes it clear that:
1. "any" is short for "interface {}"
2. "interface {}" has no *specific types*
3. "interface { int; any }" is an *intersection* of *specific types*

You are taking the intersection of the set of one type (int) with the empty 
set, and therefore the result is the empty set.  Exactly as the comment 
says.

On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote:

> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:
>
>> 1. interface { a;b } is intersection. The "Intersection" between two sets 
>> means things which exist in both sets simultaneously.
>> 2. interface { a|b } is union.  "Union" means a set of things which which 
>> exist in set A *or* set B.
>>
>> Quoting from the spec:
>> *"the predeclared type *any* is an alias for the empty interface." *
>> *"interface{} // no specific types"*
>> *"For an interface with type elements, 𝑆 is the intersection of the 
>> specific types of its type elements."*
>>
>> Can you see now?
>>
>
> The explanation is as what I think.
> But what is your conclusion? Is it a mistake in spec?
>

-- 
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/4a72d63e-011e-43ee-9f44-1dfda13a591cn%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[tapi...@gmail.com]

On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote:

> 1. interface { a;b } is intersection. The "Intersection" between two sets 
> means things which exist in both sets simultaneously.
> 2. interface { a|b } is union.  "Union" means a set of things which which 
> exist in set A *or* set B.
>
> Quoting from the spec:
> *"the predeclared type *any* is an alias for the empty interface." *
> *"interface{} // no specific types"*
> *"For an interface with type elements, 𝑆 is the intersection of the 
> specific types of its type elements."*
>
> Can you see now?
>

The explanation is as what I think.
But what is your conclusion? Is it a mistake in spec?

-- 
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/09ef1de2-de2d-42e0-ae2f-6188530c04den%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[Brian Candler]

1. interface { a;b } is intersection. The "Intersection" between two sets 
means things which exist in both sets simultaneously.
2. interface { a|b } is union.  "Union" means a set of things which which 
exist in set A *or* set B.

Quoting from the spec:
*"the predeclared type *any* is an alias for the empty interface." *
*"interface{} // no specific types"*
*"For an interface with type elements, 𝑆 is the intersection of the 
specific types of its type elements."*

Can you see now?

>

-- 
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/2ee4f634-f91b-4bf2-bcb9-84e606c33ba9n%40googlegroups.com.

[go-nuts] Re: An mistake in tip spec?

[tapi...@gmail.com]

Should it be

interface{ int | any } // no specific types (intersection is empty)

instead
On Wednesday, January 5, 2022 at 11:20:16 PM UTC+8 tapi...@gmail.com wrote:

> https://tip.golang.org/ref/spec#Structure_of_interfaces
>
>interface{ int; any } // no specific types (intersection is empty)
>
>
> Why the constraint has no specific types. Doesn't it specify int?
>

-- 
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/09badb9a-0f63-4f49-9e07-be6266969f96n%40googlegroups.com.