[generics] use interfaces in type lists

[Davor Kapša]

Hi, 

Is it planned to combine type list with embed interfaces,

or it is too confusing ?

type numeric interface {

type integers, floats

}

type integers interface {

type int, int8, int16, int32, int64, unsigneds

}

type unsigneds interface {

type uint, uint8, uint16, uint32, uint64

}

type floats interface {

type float32, float64

}

https://go2goplay.golang.org/p/6X5WZxWIcHE

Thanks for current draft, it feels very idiomatic to me.

--- Davor

[Ian Lance Taylor]

Using an interface type in a type list has a defined meaning: the type
argument must have as its underlying type that interface type. It
doesn't mean what I think you want it to mean, which is to serve as a
union of the type lists of the interface types. What you suggest
would not be impossible, but it would mean making an exception to the
rules for type lists.

Ian

[Steven Blenkinsop]

On Fri, Jul 3, 2020 at 3:05 PM, Ian Lance Taylor <ia...@golang.org> wrote:

Using an interface type in a type list has a defined meaning: the type
argument must have as its underlying type that interface type.  It
doesn't mean what I think you want it to mean, which is to serve as a
union of the type lists of the interface types.  What you suggest
would not be impossible, but it would mean making an exception to the
rules for type lists.

One way to disambiguate would be to define a pseudo-type, I(T) for some interface type I and type T which is identical to T if T implements I, and is otherwise an empty type that doesn't match any other type. This could also solve the type switching on type parameters question, since 

switch t := t.(type) {

case interface { type int }(T):

   ...

}

would match for a value t of type T if the underlying type of T is int. The syntax is a bit unwieldy, but it makes it clear that we're matching based on the type-list semantics and disambiguates between matching to an interface type vs. matching to a concrete type that implements an interface. That it looks like a conversion shouldn't be too much of an issue, since generic functions are also to be followed by either a type list or a value list.

These pseudo-types would probably only make sense in type lists and type switches, just as null is only usable as a pseudo-type in type switches.

There might be cleaner ways of doing this, though.