On Thu, Jan 6, 2022 at 8:18 PM Ian Lance Taylor <i...@golang.org> wrote:
> On Thu, Jan 6, 2022 at 8:59 AM 'Axel Wagner' via golang-nuts
> <golang-nuts@googlegroups.com> 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
<https://tip.golang.org/ref/spec#Interface_types> 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 "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%3DyX2uybnUfxWswRUHww%2B%2BdUQsvP%2B_4FA%40mail.gmail.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/CAEkBMfG_67AUZvYbunZ%3DxoDGbAW9RfRvFtSnep%3DEYoPWsrqCDg%40mail.gmail.com.
