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

go/types, types2: type parameter order is significant when it should not be #40789

Closed
rogpeppe opened this issue Aug 14, 2020 · 5 comments
Closed
Assignees
Milestone

Comments

@rogpeppe
Copy link
Contributor

@rogpeppe rogpeppe commented Aug 14, 2020

commit 722af87

The following program fails with the error "K does not satisfy comparable", in the copyMap function definition when AFAICS K is declared correctly as having a comparable constraint.

package main

import "fmt"

func main() {
	m := map[string]int{
		"a": 6,
		"b": 7,
	}
	fmt.Println(copyMap[map[string]int, string, int](m))
}

type Map[K comparable, V any] interface {
	type map[K] V
}

func copyMap[M Map[K, V], K comparable, V any](m M) M {
	m1 := make(M)
	for k, v := range m {
		m1[k] = v
	}
	return m1
}```

If the type parameters are reordered to put `K` first, the example [works OK](https://go2goplay.golang.org/p/JwcN6NspdYu).
@rogpeppe rogpeppe changed the title cmd/go2go: cmd/go2go: type parameter order is significant when it should not be Aug 14, 2020
@ianlancetaylor ianlancetaylor added this to the Unreleased milestone Aug 14, 2020
@AndrewWPhillips
Copy link

@AndrewWPhillips AndrewWPhillips commented Sep 17, 2020

Here's something simpler to demonstrate the problem.

package main

type A[X comparable] interface {
	type []X
}

func f[B A[X], X comparable]() B {
	return nil
}

func main() {
}

Loading

@griesemer
Copy link
Contributor

@griesemer griesemer commented Sep 23, 2020

Thanks for this. Another case where the prototype type-checks too eagerly. This is a problem we need to solve in general in a real implementation (probably requires a two-phase approach). Addressing this should resolve a large number of bugs (not just with generics but elsewhere as well).

Loading

@griesemer griesemer removed this from the Unreleased milestone Feb 17, 2021
@griesemer griesemer added this to the Go1.17 milestone Feb 17, 2021
@griesemer griesemer removed this from the Go1.17 milestone Apr 14, 2021
@griesemer griesemer added this to the Go1.18 milestone Apr 14, 2021
@griesemer griesemer changed the title cmd/go2go: type parameter order is significant when it should not be go/types, types2: type parameter order is significant when it should not be Jun 29, 2021
@gopherbot
Copy link

@gopherbot gopherbot commented Jun 29, 2021

Change https://golang.org/cl/331690 mentions this issue: [dev.typeparams] cmd/compile/internal/types2: delay interface check for type bounds

Loading

@griesemer
Copy link
Contributor

@griesemer griesemer commented Jun 29, 2021

The above CL fixes this issue for types2. The initial example still doesn't fully compile due to an unrelated error in the compiler.

Loading

gopherbot pushed a commit that referenced this issue Jul 1, 2021
…or type bounds

While at it, clean up code for collecting/declaring type parameters.

For #40789.

Change-Id: I0855137d5ee85c0ae2fa60d33b28c24a33132fbc
Reviewed-on: https://go-review.googlesource.com/c/go/+/331690
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@griesemer
Copy link
Contributor

@griesemer griesemer commented Aug 4, 2021

This was fixed in the type checkers by

https://golang.org/cl/331690 in types2
https://golang.org/cl/335034 in go/types

Loading

@griesemer griesemer closed this Aug 4, 2021
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
5 participants