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/compile: no need to infer type arguments for blank type parameters with any constraint #50547

Closed
griesemer opened this issue Jan 11, 2022 · 3 comments
Closed

cmd/compile: no need to infer type arguments for blank type parameters with any constraint #50547

griesemer opened this issue Jan 11, 2022 · 3 comments
Labels
FrozenDueToAge generics Issue is related to generics NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. TypeInference Issue is related to generic type inference
Milestone
Go1.19

Comments

@griesemer
Copy link
Contributor 

package p

func f[_ any]() {}

func _() {
        f()
}

produces the error

cannot infer _

but blank type parameters can't be used and thus it doesn't matter what their corresponding argument is if the constraint is any (any type will satisfy that constraint). If the constraint is not any we should still infer the type argument so we can verify constraint satisfaction.

Maybe we shouldn't report an error in this case. Or maybe this is so esoteric that is doesn't matter. Filing this issue so we document decision (and perhaps implement it).

cc: @ianlancetaylor @findleyr for input
@griesemer griesemer added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jan 11, 2022
@griesemer griesemer added this to the Go1.19 milestone Jan 11, 2022
@griesemer griesemer self-assigned this Jan 11, 2022
@findleyr
Copy link
Contributor

In my opinion we shouldn't do anything special for this case, i.e. we should continue to report an error. It doesn't really matter that the type parameter is blank here -- all that really matters is that the function type does not depend on the type parameter.
We could equally well support the following:

func f[A, B any](a A) A { return a }

var g = f(0)

Choosing to omit this error for blank type parameters seems somewhat arbitrary. In your proposal, would we support the example here if B were _? If so, that's rather more complex as we'd have to short-circuit inference.

@bcmills
Copy link
Contributor

bcmills commented Jan 11, 2022

If we omitted the error for the blank-parameter case, then it would be impossible to change the name of the parameter from _ to any other name — even though that kind of renaming should otherwise be completely compatible.

@griesemer
Copy link
Contributor Author

The arguments against not inferring (i.e., for not doing anything special) in this case are convincing. Let's not make any changes. Closing.

@ianlancetaylor ianlancetaylor added TypeInference Issue is related to generic type inference generics Issue is related to generics labels Apr 18, 2022
@golang golang locked and limited conversation to collaborators Jun 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge generics Issue is related to generics NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. TypeInference Issue is related to generic type inference
Projects
None yet
Milestone
Go1.19
Development

No branches or pull requests
5 participants
@ianlancetaylor @bcmills @griesemer @gopherbot @findleyr