On Wed, Jun 17, 2020 at 4:33 PM jimmy frasche <soapboxcic...@gmail.com> wrote:
>
> If I merge the two examples I still get an error
> https://go2goplay.golang.org/p/TNYLDLokGCQ
>
> prog.go2:21:2: int does not satisfy Z (int not found in ⊥)
I think that may be a bug in the type checker, which may not be quite
updated to what the design draft says.
CC'ed Robert.
Ian
> On Wed, Jun 17, 2020 at 4:24 PM Ian Lance Taylor <i...@golang.org> wrote:
> >
> > On Wed, Jun 17, 2020 at 3:52 PM jimmy frasche <soapboxcic...@gmail.com>
> > wrote:
> > >
> > > The only case I mean is when the intersection of the type lists is ∅.
> > > That's easy to check and always wrong afaict.
> >
> > Unfortunately I don't think it's that simple.
> >
> > type MyInt int
> >
> > type I1 interface {
> > type int
> > }
> >
> > type I2 interface {
> > type MyInt
> > }
> >
> > type I3 interface {
> > I1
> > I2
> > }
> >
> > It might seem like the intersection of the type lists in I1 and I2 is
> > the empty set, but since we match on underlying types I3 does match
> > "int".
> >
> > Ian
> >
> >
> > > On Wed, Jun 17, 2020 at 3:47 PM Ian Lance Taylor <i...@golang.org> wrote:
> > > >
> > > > On Wed, Jun 17, 2020 at 1:09 PM jimmy frasche <soapboxcic...@gmail.com>
> > > > wrote:
> > > > >
> > > > > This isn't a bug per se, but I can file one if requested.
> > > > >
> > > > > https://go2goplay.golang.org/p/AWynhg6ya7h
> > > > >
> > > > > Since embedding interfaces with type lists uses the intersection of
> > > > > the items in the type list, it's possible to create an interface that
> > > > > cannot be satisfied by any type.
> > > > >
> > > > > Currently this does not cause an error until you attempt to
> > > > > instantiate something that uses such an interface as a bound.
> > > > >
> > > > > I think it would be more useful to raise the error when defining the
> > > > > interface that cannot be used as it's likely an error—or at least I
> > > > > can see no valid use for creating an unsatisfiable constraint.
> > > >
> > > > In order to ensure that all Go compilers act the same, we would have
> > > > to very carefully define the cases that are not accepted. This is a
> > > > little harder than it sounds since matching is done on underlying
> > > > types. At least for now I tend to think that it would be better to
> > > > make this a vet check. But I don't feel all that strongly about it.
> > > >
> > > > 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/CAOyqgcVVvzsWhGUM_2CAEMOiq%2BAus1TP7QgOQyTjYU8-EDX0vQ%40mail.gmail.com.
