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

Make go compiler use non-generic/concrete version of function if both generic and concrete versions exist #40538

Closed
susugagalala opened this issue Aug 3, 2020 · 2 comments

Comments

@susugagalala
Copy link

@susugagalala susugagalala commented Aug 3, 2020

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

$ go version
go version go-dev.go2go-20200801 darwin/amd64

Does this issue reproduce with the latest release?

Yes, with the above go2go branch and commit date

What operating system and processor architecture are you using (go env)?

darwin amd64

What did you do?

$go tool go2go run program.go2
// program.go2
package main

func Print(s []int) {
for _, v := range s {
println(v)
}
}

func Print[T](s []T) {
for _, v := range s {
println(v)
}
}

func main() {
Print([]int{1, 2, 3})
}

What did you expect to see?

1
2
3
NOTE: I'd like to see the compiler use non-generic version if both generic/concrete functions exist.
That also applies to generic types as well.
This also mean existing client code doesn't have to change when generics finally come to Go, so Go2 generics is still effectively backward compatible with Go1.

What did you see instead?

type checking failed for main
/var/folders/v9/jczv1kzj41329fqmmsp9m1c40000gn/T/go2go-run303878027/program.go2:9:6: Print redeclared in this block
/var/folders/v9/jczv1kzj41329fqmmsp9m1c40000gn/T/go2go-run303878027/program.go2:3:6: other declaration of Print

@davecheney
Copy link
Contributor

@davecheney davecheney commented Aug 3, 2020

@susugagalala what you are asking for is function overloading which go does not support. There can only be one declaration of a function (or method) irrespective of the arguments.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 3, 2020

I agree with @davecheney . This could arguably be considered for future versions of the language. It will not be part of the initial generics language change proposal (if we ever get to that point).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.