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.

Reply via email to