[generics] the empty type list

[jimmy frasche]

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.

[Ian Lance Taylor]

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

[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.

[Ian Lance Taylor]

On Wed, Jun 17, 2020 at 3:52 PM jimmy frasche <soapbo...@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

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

[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).

[Ian Lance Taylor]

On Wed, Jun 17, 2020 at 4:33 PM jimmy frasche <soapbo...@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.

[Bryan C. Mills]

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

[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.

--
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...@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.

[Axel Wagner]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%40mail.gmail.com.

[Axel Wagner]

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{}.

[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.

[Bryan C. Mills]

On Thu, Jun 18, 2020 at 4:19 PM 'Axel Wagner' via golang-nuts <golan...@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).

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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFwkVmbva1bRYbHX3D6oUhufHvdr-Ebb0GY0u3j_fyTUA%40mail.gmail.com.

[jimmy frasche]

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

[Jesper Louis Andersen]

On Thu, Jun 18, 2020 at 10:14 PM Axel Wagner <axel.wa...@googlemail.com> wrote:

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

In my experience, trying to reject the degenerate corner cases in logic is only going to hurt you in the long run. That is my major argument.