Skip to content

go/types, types2: make constraint type inference more flexible for some channel types (?) #45920

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.

Sign up for GitHub

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
Closed
griesemer opened this issue May 3, 2021 · 6 comments
Closed

go/types, types2: make constraint type inference more flexible for some channel types (?) #45920

griesemer opened this issue May 3, 2021 · 6 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.18

Comments

@griesemer
Copy link
Contributor

Constraint type inference works as expected for

package p

func Recv[T any, C interface{ type chan T }](ch C)

func _(ch chan int) {
	Recv(ch) // T is inferred as int
}

but fails for

package p

func Recv[T any, C interface{ type chan T, <-chan T }](ch C)

func _(ch chan int) {
	Recv(ch) // inference fails
}

per the current proposal specification (constraint type inference expects exactly one type in the type list/set of the constraint for which inference is used).

This seems like it might be a common case; perhaps we need to special case channels that are the same but for their directions.

Reported by @rogpeppe in #43671.
@griesemer griesemer added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label May 3, 2021
@griesemer griesemer added this to the Go1.18 milestone May 3, 2021
@griesemer griesemer self-assigned this May 3, 2021
@griesemer griesemer mentioned this issue May 3, 2021
Closed
@ianlancetaylor
Copy link
Member

I think that what is most important for now is that the inference rules be as simple as possible. Constraint type inference is already quite complicated. I don't think that we should make it more complicated. There will always be cases where a person can easily see what the answer is even if the inference algorithm can't.

@rogpeppe
Copy link
Contributor

rogpeppe commented May 6, 2021

FWIW here's another case that came up while discussing possible future directions for encoding/json: https://go2goplay.golang.org/p/27Vkw9dnhNZ

It would be kinda nice to have constraint type inference work there.

@griesemer
Copy link
Contributor Author

The good thing about type inference is that we can continue to fine-tune it (and make it more powerful) without affecting existing code (i.e. w/o affecting backward-compatibility).

@griesemer
Copy link
Contributor Author

For this to work we need to relax the structural type of constraints to ignore channel directions. This may have some unexpected consequences. Will experiment. If the relaxation is all that's needed, we can address this. Otherwise we will stick to the existing rules.

@griesemer
Copy link
Contributor Author

Removing release-blocker again. We will be ok with or without this.

@griesemer griesemer added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed release-blocker labels Nov 1, 2021
@gopherbot gopherbot removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Nov 1, 2021
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/363075 mentions this issue: cmd/compile/internal/types2: slightly relax notion of structural type

@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.18
Development

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