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

Jump to bottom

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
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Unreleased

Comments

@griesemer
Copy link
Contributor

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
@griesemer griesemer self-assigned this Jun 20, 2020
@griesemer griesemer added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jun 20, 2020
@griesemer griesemer added this to the Unreleased milestone Jun 20, 2020
@griesemer griesemer mentioned this issue Jun 20, 2020
Closed
@ianlancetaylor
Copy link
Contributor

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

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

Agreed.

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

gopherbot pushed a commit that referenced this issue Jun 20, 2020
@griesemer
[dev.go2go] go/types: a type constraint must be an interface
cbdb93d 
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
Contributor

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.

@golang golang locked and limited conversation to collaborators Jun 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
4 participants
@ianlancetaylor @bcmills @griesemer @gopherbot