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: type inference fails on a case which looks simple #63750

Closed
zigo101 opened this issue Oct 26, 2023 · 4 comments
Closed

cmd/compile: type inference fails on a case which looks simple #63750

zigo101 opened this issue Oct 26, 2023 · 4 comments
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime.

Comments

@zigo101
Copy link

zigo101 commented Oct 26, 2023

What version of Go are you using (go version)?

$ go version
go version go1.21.3 linux/amd64

Does this issue reproduce with the latest release?

What did you do?

package main

func foo[C ~*T | ~[]T, T any](v C) {} // compiles

func main() {
	foo(new(int))       // cannot infer T
	foo(make([]int, 3)) // cannot infer T
}

What did you expect to see?

Compiles.

What did you see instead?

Fails to compile.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Oct 26, 2023
@zigo101 zigo101 changed the title cmd/compile: type inference failas on a case which looks simple cmd/compile: type inference fails on a case which looks simple Oct 26, 2023
@mauri870
Copy link
Member

/cc @golang/compiler

@griesemer griesemer self-assigned this Oct 26, 2023
@griesemer
Copy link
Contributor

Unfortunately we can't do any inference in this case because the constraint C doesn't have a core type.
Closing because this is a known limitation of the language, not an actual bug.
Eventually we need a concrete proposal to move forward.

@dr2chase
Copy link
Contributor

This case would look simpler if it included a comment explaining what was thought to be happening.

@griesemer
Copy link
Contributor

@dr2chase In both cases, T should be inferred to be int.
@go101 What we need to see to move forward with cases like these (type inference) is really good real-life examples where this matters. Functions operating on type parameters which have no core types can't do a whole lot with values of such type parameters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
None yet
Development

No branches or pull requests

5 participants