[generics] Do we really need explicit type lists in constraints?

[Bruno Albuquerque]

It looks to me one point of contention on using interfaces instead of contracts is the fact that now interfaces have to support type lists but only when used as contracts. This, no matter how you slice it, looks ugly.

Now type lists are there to support built-in operations like operators in general and range support. there is a finite (and relatively small) set of combinations of types that make sense.

Also there is already the intention of providing "contracts" like Comparable in pre-existing libraries.

There is also precedent for "magical" things in the language (range can operate on slices of any type).

So, with all that in mind, wouldn't it be possible for the language to offer all the possible reasonable type combinations as built-in contracts in a way that they could be embedded in other interfaces? They would be a bit magical as their constraints are, under the hood, on types (not methods), but I guess this would make things less ugly.

[burak serdar]

On Thu, Jun 18, 2020 at 4:59 PM Bruno Albuquerque <b...@gmail.com> wrote:
>
> It looks to me one point of contention on using interfaces instead of contracts is the fact that now interfaces have to support type lists but only when used as contracts. This, no matter how you slice it, looks ugly.

I agree, it looks ugly.

I wrote a proposal (first proposal?) about a year ago about these type
lists. The idea with type lists had two aspects then: first, you have
to somehow use primitive types as constraints without operator
overloading, and second, you can use existing types as constraints
instead of dealing with type traits. I understand that the concept of
contracts could be confusing. But I believe changing the definition of
interfaces would be even more confusing. Interfaces already cause a
lot of problems for people coming from other languages like Java.

One suggestion could be using type lists where needed:

func f(type T int string bool) (input T)

This can get verbose, so maybe a new keyword?

typelist TL int, string,bool
func f(type T TL)(input T)

This goes back to contracts though. Maybe "contract" could be renamed
to less confusing "typelist"?

Also, there is no point in restricting typelist to primitives:

typelist TL int, string, bool, SomeInterface

I think such a typelist can do everything the interface-with-typelist
can without changing the definition of what interface means.

Just some thoughts, I'm still reading the design doc...

>
> Now type lists are there to support built-in operations like operators in general and range support. there is a finite (and relatively small) set of combinations of types that make sense.
>
> Also there is already the intention of providing "contracts" like Comparable in pre-existing libraries.
>
> There is also precedent for "magical" things in the language (range can operate on slices of any type).
>
> So, with all that in mind, wouldn't it be possible for the language to offer all the possible reasonable type combinations as built-in contracts in a way that they could be embedded in other interfaces? They would be a bit magical as their constraints are, under the hood, on types (not methods), but I guess this would make things less ugly.
>

> --
> 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/CAEd86Tz%2B6vfp1C_kFA82Mw5z__%3D5SLrc%3Dnu3od1AKBVCCRtBPQ%40mail.gmail.com.

[Ian Lance Taylor]

Thanks. It's not as easy as it sounds. There are many different type
combinations in Go. It winds up being something like 25 new names to
add to the language. That is a lot.

Also, consider cases like
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#composite-types-in-constraints
. With those you get even more cases.

It's likely that in practice the common constraints will be in a
standard library constraints package, so relatively few people will
write type lists. But the constraints package can be written in Go,
which is nice, and people will be able to reach for complex cases with
their own type lists when they need them, which is also nice.

Ian