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.
