Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go2go: constraints that are type parameters #39723

Closed
griesemer opened this issue Jun 20, 2020 · 4 comments
Closed

cmd/go2go: constraints that are type parameters #39723

griesemer opened this issue Jun 20, 2020 · 4 comments
Assignees
Labels
Milestone

Comments

@griesemer
Copy link
Contributor

@griesemer griesemer commented Jun 20, 2020

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
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 20, 2020

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
Copy link

@gopherbot gopherbot commented Jun 20, 2020

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

@griesemer
Copy link
Contributor Author

@griesemer griesemer commented Jun 20, 2020

Agreed.

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

@griesemer griesemer closed this Jun 20, 2020
gopherbot pushed a commit that referenced this issue Jun 20, 2020
In particular, it cannot be a type parameter
with an operational type that is an interface.

Fixes #39723.

Change-Id: Ia6b65eaecd472dd71b1c9f7631ce1872f06e5a6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/239161
Reviewed-by: Robert Griesemer <gri@golang.org>
@bcmills
Copy link
Member

@bcmills bcmills commented Jun 22, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.