cmd/go2go: constraints that are type parameters

[griesemer]

This is a design question: Should it be possible to use a type parameter as a constraint? For instance, should this be accepted:

func _(type A interface{ type interface{} }, B A)()

A is a type parameter, not an interface, but the constraint for A ensures that A eventually is an interface. This case even appears to satisfy the type-checker. More complex cases fail at the moment.

See also the 2nd example from #39711.

cc: @ianlancetaylor

[ianlancetaylor]

I do not think this should be permitted. The type constraints should create a contract between the function caller and the function definition. If the function caller is permitted to set the constraint, then there is no contract.

Also, note that we cannot deduce anything about permitted operations from this kind of constraint. So it does not permit any behavior in the generic function. All it does is give a way for the caller to constrain the type arguments--but the caller is already determining the type arguments anyhow. I can't think of anything that this would permit that is not currently permitted.

So this seems both undesirable and unhelpful.

[gopherbot]

Change https://golang.org/cl/239161 mentions this issue: [dev.go2go] go/types: a type constraint must be an interface

[griesemer]

Agreed.

It turns out that the only reason this worked in some cases was due to a bug. Now fixed on dev.go2go.

[bcmills]

Also, note that we cannot deduce anything about permitted operations from this kind of constraint.

We should be able to deduce that B is assignable to A, but I agree that the need for a type-list to make this work at all implies that it would not be very useful as a pointwise addition to the design.