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/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
Labels
generics NeedsDecision TypeInference
Milestone

Comments

@griesemer
Copy link
Contributor

@griesemer griesemer commented Jan 11, 2022

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

@findleyr findleyr commented Jan 11, 2022

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
Member

@bcmills 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

@griesemer griesemer commented Jan 11, 2022

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 generics labels Apr 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
generics NeedsDecision TypeInference
Projects
None yet
Development

No branches or pull requests

4 participants