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.

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

proposal: spec: permit unused type parameters to not be inferred #57620

Closed
twmb opened this issue Jan 5, 2023 · 4 comments
Closed

proposal: spec: permit unused type parameters to not be inferred #57620

twmb opened this issue Jan 5, 2023 · 4 comments
Labels
generics Issue is related to generics Proposal TypeInference Issue is related to generic type inference
Milestone
Proposal

Comments

@twmb
Copy link
Contributor

twmb commented Jan 5, 2023 •
edited

I was recently trying roughly the following segment of code expecting it to work:

https://go.dev/play/p/yTVhxJ82pMR

Lines 47 and 48 are commented out; lines 53 and 54 are what I would have to do if I want to use First. If possible, it'd be great to not have to fully specify the types and instead rely entirely on type inference.

Speaking as a complete newbie / uninformed person here, I'd think the algorithm would be:

For slices,

  • Input S matches left side of union ~[]V
  • V is inferred to be the value type of the input slice
  • K is not required and is ignored

For maps,

  • Input S matches right side of union ~map[K]V
  • K is inferred to be the key type of the input map
  • V is inferred to be the value type of the input map

I recognize this is a naive and simple proposal that absolutely does not capture the underlying complexity. Go also currently requires all types to be specified, and in the slice case, there is no K; this requirement would need to be relaxed in the type union case.

The closest related issue I see is #56975, but that is different because the proposal is specific to functions and is actually not about a union.
@twmb twmb added the Proposal label Jan 5, 2023
@gopherbot gopherbot added this to the Proposal milestone Jan 5, 2023
@ianlancetaylor ianlancetaylor added generics Issue is related to generics TypeInference Issue is related to generic type inference labels Jan 5, 2023
@ianlancetaylor ianlancetaylor changed the title proposal: spec: fully infer types in unions of generic types proposal: spec: permit unused type parameters to not be inferred Jan 5, 2023
@antichris
Copy link

I think there are actually two issues that you (or, at least, your code sample) might be conflating here:

The former might get addressed by #58650.

The severity of the latter (about which the title of this proposal seems to be) can be reduced by shifting some of the type parameters around. I'm doubtful a general solution in the inference algorithm is reasonably possible.

Also, the OP playground code uses an interface type switch, which is evaluated at runtime and would require K to be always known, since one of its cases does use that.

@griesemer
Copy link
Contributor

I agree that there are (at least) two issues here:

  1. allow unused type parameters to not be inferred, and
  2. make type inference more powerful in the presence of unions in constraints

Regarding 1), which the proposal title is about: I don't have a good use case where one would want to specify a type parameter that is never used (as opposed to only used depending on the types of other type parameters), but in the former case, such type parameters could be named _ (blank): they would be present but can't be accessed. It would be easy to simply assign them an arbitrary type argument.

Ignoring type parameters depending on the value of other type arguments (or the code in a function body) most likely is not something we're going to take on.

Regarding 2): I think that requires a separate, independent proposal.

@griesemer
Copy link
Contributor

Regarding 1) above: I don't think we should do this.
Regarding 2): waiting for the respective proposal.

@twmb
Copy link
Contributor Author

twmb commented May 25, 2023

I don't have the bandwidth nor will to create a second proposal, this isn't the most important to me. Thanks for the consideration, though. I'll close this proposal.

@twmb twmb closed this as completed May 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
generics Issue is related to generics Proposal TypeInference Issue is related to generic type inference
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
5 participants
@antichris @twmb @ianlancetaylor @griesemer @gopherbot