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/go2go: type inference could be less strict when there are interface arguments #40055

Open
rogpeppe opened this issue Jul 5, 2020 · 3 comments

Comments

@rogpeppe
Copy link
Contributor

@rogpeppe rogpeppe commented Jul 5, 2020

The following program fails:

func Equal(type T comparable)(x, y T) bool {
	return x == y
} 

func main() {
	var x interface{} = 5
	var y = 5

	fmt.Println(Equal(x, y))
}

The error is:

prog.go2:15:23: type int of y does not match inferred type interface{} for T

Although it's true that the types don't match exactly, it seems to me that it might be nice
to allow the type argument to unify to interface{} in the same way that we allow
a concrete type to be passed to an interface type.

@mmaedel
Copy link

@mmaedel mmaedel commented Jul 5, 2020

hi @rogpeppe
i am with you and if with a 'comparable', it would be nice to even have it in basic types...

this:

func main() {
var x interface{} = 5
var y = 6.1

fmt.Println(Equal(x, interface{}(y)))

}

should also work for:

func main() {
var x = 5
var y = 6.1

fmt.Println(Equal(x, y))

}

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jul 5, 2020

I am very concerned about avoiding any possible confusion in which type inference does not act as people expect. This is based on the complexity of the C++ equivalent to type inference, which observably confuses people. I would rather say that if there is any confusion, the programmer must explicitly state the desired type.

@cagedmantis cagedmantis added this to the Unplanned milestone Jul 6, 2020
@bcmills
Copy link
Member

@bcmills bcmills commented Jul 17, 2020

I too would like to see better type inference here, but I think this is the sort of refinement that can (and should!) wait until after the initial implementation and release of generics, so that we can gather empirical evidence to weigh the cost (of more difficulty reasoning about inference) against the benefit (of avoiding the verbosity and distraction of “obvious” annotations).

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
6 participants
You can’t perform that action at this time.