Re: [go-nuts] [generics] the empty type list

[jimmy frasche]

I think I'm missing something. How is nil not an inhabitant?

On Thu, Jun 18, 2020 at 6:48 PM Bryan C. Mills  wrote:
>
> On Thu, Jun 18, 2020 at 4:19 PM 'Axel Wagner' via golang-nuts 
>  wrote:
>>
>> Addendum: In Go, every type needs to be inhabited by at least one value - 
>> it's zero value. And we already have a type that can take *exactly* one 
>> value, namely struct{}.
>
>
> That is true, but struct{} is the unit type — not the bottom element of the 
> interface-type lattice.
> struct{} can be added as a field of any struct with no effect on 
> comparability or equality, and adds no bits of information (it is a 
> multiplicative unit).
> As an interface value, struct{} carries one “bit” of information: its type.
> But struct{} has no methods and is not assignable to any interface type: 
> therefore, it is not the bottom type of the interface lattice.
>
> In contrast, the interface of the empty type-list, if such a thing could 
> exist at run-time, would presumably have only one value as well: the nil 
> interface value.
> The nil interface value is a member of every other interface type, so the 
> empty type-list would be assignable to every other interface type (it is the 
> bottom of the interface lattice).
> Conceptually, it has all possible methods, but there would be no point in 
> calling them: they all result in a nil-panic.
> As a struct field, the empty interface is also a multiplicative unit (it adds 
> no bits of information).
> However, it is also an additive unit: the union of the empty type-list and 
> any other interface is identical to the other interface (because every other 
> interface already admits the nil interface value).
>
>> On Thu, Jun 18, 2020, 22:13 Axel Wagner  
>> wrote:
>>>
>>> These arguments would be more convincing, if Go wouldn't already reject 
>>> interfaces impossible to implement: https://play.golang.org/p/dYm8js26qml
>>>
>>> On Thu, Jun 18, 2020, 17:26 Jesper Louis Andersen 
>>>  wrote:

 It is a type which cannot be inhabited by a term. These exist and often 
 have uses. As Bryan wrote they also completes the type lattice, so 
 rejecting them is often a lot of work for little gain.

 If you want examples, look up phantom types, where an uninhabited type is 
 used as a tag for ensuring compile time restrictions.

 On Wed, Jun 17, 2020, 22:09 jimmy frasche  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.
>
> --
> 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/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%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/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%40mail.gmail.com.
>>
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/CsA1FJKZ4qs/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CAEkBMfFwkVmbva1bRYbHX3D6oUhufHvdr-Ebb0GY0u3j_fyTUA%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/CANG3jXJX0gf%3D%3DniCa4MtQ7-3Q6rU%3DQr2tTpKntMVMqDVOo4BMw%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

['Bryan C. Mills' via golang-nuts]

On Thu, Jun 18, 2020 at 4:19 PM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Addendum: In Go, every type needs to be inhabited by at least one value -
> it's zero value. And we already have a type that can take *exactly* one
> value, namely struct{}.
>

That is true, but struct{} is the unit type — not the bottom element of the
interface-type lattice.
struct{} can be added as a field of any struct with no effect on
comparability or equality, and adds no bits of information (it is a
multiplicative unit).
As an interface value, struct{} carries one “bit” of information: its type.
But struct{} has no methods and is not assignable to any interface type:
therefore, it is not the bottom type of the interface lattice.

In contrast, the interface of the empty type-list, if such a thing could
exist at run-time, would presumably have only one value as well: the nil
interface value.
The nil interface value is a member of every other interface type, so the
empty type-list would be assignable to every other interface type (it is
the bottom of the interface lattice).
Conceptually, it has all possible methods, but there would be no point in
calling them: they all result in a nil-panic.
As a struct field, the empty interface is also a multiplicative unit (it
adds no bits of information).
However, it is also an additive unit: the union of the empty type-list and
any other interface is identical to the other interface (because every
other interface already admits the nil interface value).

On Thu, Jun 18, 2020, 22:13 Axel Wagner 
> wrote:
>
>> These arguments would be more convincing, if Go wouldn't already reject
>> interfaces impossible to implement: https://play.golang.org/p/dYm8js26qml
>>
>> On Thu, Jun 18, 2020, 17:26 Jesper Louis Andersen <
>> jesper.louis.ander...@gmail.com> wrote:
>>
>>> It is a type which cannot be inhabited by a term. These exist and often
>>> have uses. As Bryan wrote they also completes the type lattice, so
>>> rejecting them is often a lot of work for little gain.
>>>
>>> If you want examples, look up phantom types, where an uninhabited type
>>> is used as a tag for ensuring compile time restrictions.
>>>
>>> On Wed, Jun 17, 2020, 22:09 jimmy frasche 
>>> 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.

 --
 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/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%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/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%40mail.gmail.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/CsA1FJKZ4qs/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAEkBMfFwkVmbva1bRYbHX3D6oUhufHvdr-Ebb0GY0u3j_fyTUA%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/CAKWVi_QQxkGAcdWNSozOeujF-vw2_mJNLuFibVN0JDsvByELcQ%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

[jimmy frasche]

The constraint can't be used for phantom types. If C is an interface
with an empty type list and P is given by
type P(type T C) struct{}
you can't instantiate P because no type can satisfy C.

C is not the type with 0 inhabitants: it's a constraint on types that
cannot be satisfied.

I don't see how it can be used in any valid program or why it would be
hard to detect. I am a little fuzzy on when type lists bring the
underlying type into play, though.

On Thu, Jun 18, 2020 at 1:17 PM Axel Wagner
 wrote:
>
> Addendum: In Go, every type needs to be inhabited by at least one value - 
> it's zero value. And we already have a type that can take *exactly* one 
> value, namely struct{}.
>
> On Thu, Jun 18, 2020, 22:13 Axel Wagner  wrote:
>>
>> These arguments would be more convincing, if Go wouldn't already reject 
>> interfaces impossible to implement: https://play.golang.org/p/dYm8js26qml
>>
>> On Thu, Jun 18, 2020, 17:26 Jesper Louis Andersen 
>>  wrote:
>>>
>>> It is a type which cannot be inhabited by a term. These exist and often 
>>> have uses. As Bryan wrote they also completes the type lattice, so 
>>> rejecting them is often a lot of work for little gain.
>>>
>>> If you want examples, look up phantom types, where an uninhabited type is 
>>> used as a tag for ensuring compile time restrictions.
>>>
>>> On Wed, Jun 17, 2020, 22:09 jimmy frasche  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.

 --
 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/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%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/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%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/CANG3jX%2BESnanNyPBdDdQdc_uZMFzU-h3fMRGqB01M-RJVtnSaQ%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

['Axel Wagner' via golang-nuts]

Addendum: In Go, every type needs to be inhabited by at least one value -
it's zero value. And we already have a type that can take *exactly* one
value, namely struct{}.

On Thu, Jun 18, 2020, 22:13 Axel Wagner 
wrote:

> These arguments would be more convincing, if Go wouldn't already reject
> interfaces impossible to implement: https://play.golang.org/p/dYm8js26qml
>
> On Thu, Jun 18, 2020, 17:26 Jesper Louis Andersen <
> jesper.louis.ander...@gmail.com> wrote:
>
>> It is a type which cannot be inhabited by a term. These exist and often
>> have uses. As Bryan wrote they also completes the type lattice, so
>> rejecting them is often a lot of work for little gain.
>>
>> If you want examples, look up phantom types, where an uninhabited type is
>> used as a tag for ensuring compile time restrictions.
>>
>> On Wed, Jun 17, 2020, 22:09 jimmy frasche 
>> 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.
>>>
>>> --
>>> 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/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%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/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%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/CAEkBMfFwkVmbva1bRYbHX3D6oUhufHvdr-Ebb0GY0u3j_fyTUA%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

['Axel Wagner' via golang-nuts]

These arguments would be more convincing, if Go wouldn't already reject
interfaces impossible to implement: https://play.golang.org/p/dYm8js26qml

On Thu, Jun 18, 2020, 17:26 Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> It is a type which cannot be inhabited by a term. These exist and often
> have uses. As Bryan wrote they also completes the type lattice, so
> rejecting them is often a lot of work for little gain.
>
> If you want examples, look up phantom types, where an uninhabited type is
> used as a tag for ensuring compile time restrictions.
>
> On Wed, Jun 17, 2020, 22:09 jimmy frasche  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.
>>
>> --
>> 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/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%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/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%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/CAEkBMfEiwoyZQZuq3w3wwJrj1z3rZe8Hb7ed7v1yohisbYMAvA%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

[Jesper Louis Andersen]

It is a type which cannot be inhabited by a term. These exist and often
have uses. As Bryan wrote they also completes the type lattice, so
rejecting them is often a lot of work for little gain.

If you want examples, look up phantom types, where an uninhabited type is
used as a tag for ensuring compile time restrictions.

On Wed, Jun 17, 2020, 22:09 jimmy frasche  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.
>
> --
> 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/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%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/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

['Bryan C. Mills' via golang-nuts]

An empty intersection of type lists cannot be instantiated with any actual 
type, but if type-list interfaces could eventually be used as run-time 
types (as suggested in 
https://golang.org/design/go2draft-type-parameters#type-lists-in-interface-types),
 
then the interface with an empty type-list would be meaningful: it would be 
an interface type whose only valid value is nil.

(In more formal terms, it would be the unique bottom element of the 
interface-type lattice, equivalent to the nil case in a type-switch today.)

On Wednesday, June 17, 2020 at 6:54:00 PM UTC-4 soapboxcicero wrote:

> The only case I mean is when the intersection of the type lists is ∅. 
> That's easy to check and always wrong afaict. 
>
> On Wed, Jun 17, 2020 at 3:47 PM Ian Lance Taylor  
> wrote: 
> > 
> > On Wed, Jun 17, 2020 at 1:09 PM jimmy frasche  
> 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/11a2ccef-f8e5-4de6-9374-c2f72e309b4fn%40googlegroups.com.

Re: [go-nuts] [generics] the empty type list

[Ian Lance Taylor]

On Wed, Jun 17, 2020 at 4:33 PM jimmy frasche  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  wrote:
> >
> > On Wed, Jun 17, 2020 at 3:52 PM jimmy frasche  
> > 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  wrote:
> > > >
> > > > On Wed, Jun 17, 2020 at 1:09 PM jimmy frasche  
> > > > 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.

Re: [go-nuts] [generics] the empty type list

[jimmy frasche]

I think that second error is a bug. I would expect that case to be the
same as if I wrote a type list that was just int (and hence not the
empty type list).

On Wed, Jun 17, 2020 at 4:33 PM jimmy frasche  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 ⊥)
>
> On Wed, Jun 17, 2020 at 4:24 PM Ian Lance Taylor  wrote:
> >
> > On Wed, Jun 17, 2020 at 3:52 PM jimmy frasche  
> > 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  wrote:
> > > >
> > > > On Wed, Jun 17, 2020 at 1:09 PM jimmy frasche  
> > > > 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/CANG3jX%2BH_kDpcba2VUwSv4RhBAFV4_ufN1JiRb6KNZ1BphRriA%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

[jimmy frasche]

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 ⊥)

On Wed, Jun 17, 2020 at 4:24 PM Ian Lance Taylor  wrote:
>
> On Wed, Jun 17, 2020 at 3:52 PM jimmy frasche  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  wrote:
> > >
> > > On Wed, Jun 17, 2020 at 1:09 PM jimmy frasche  
> > > 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/CANG3jXKE6EksKcgvPXWiP9naCXAwbc7LMihvJeDw1fatPXgS%3Dg%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

[Ian Lance Taylor]

On Wed, Jun 17, 2020 at 3:52 PM jimmy frasche  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  wrote:
> >
> > On Wed, Jun 17, 2020 at 1:09 PM jimmy frasche  
> > 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/CAOyqgcVATzqmAUBjS758Ry%3DgEwcgFmrYaKcTO8fR3oZ7V-piMg%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

[jimmy frasche]

The only case I mean is when the intersection of the type lists is ∅.
That's easy to check and always wrong afaict.

On Wed, Jun 17, 2020 at 3:47 PM Ian Lance Taylor  wrote:
>
> On Wed, Jun 17, 2020 at 1:09 PM jimmy frasche  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/CANG3jX%2BZ1H8YUaSFFTPmV-CUQgKbkWBFU48vAO6aO-Ad-p%2BuNw%40mail.gmail.com.

Re: [go-nuts] [generics] the empty type list

[Ian Lance Taylor]

On Wed, Jun 17, 2020 at 1:09 PM jimmy frasche  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/CAOyqgcXdxuzoJ5T7tLxso_5F%2B32KfSWrNi0N96202CQd0PiUog%40mail.gmail.com.