On Fri, Jul 3, 2020 at 3:05 PM, Ian Lance Taylor <[email protected]> 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.

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANjmGJtcJXYsprLD1f6mMJ5ZYW4xaAJgCFhaC5cBM2M4AxvJJg%40mail.gmail.com.

Reply via email to