it looks like this was introduced in 7473a6a#diff-8d7fac7a0925d669f941654f9b1cc5ea0be70dd93bfa3ab255456e510cd98cd7R1602 which added a PkgPath equality requirement to haveIdenticalType

If anything, this is a bug in 1.16.

If you add

	_ = ([]b.Reference)(actual)

The compiler complains that the conversion is not allowed (both in 1.16 and 1.17).

Converting slices with different named element types, even if their structure is the same, is not allowed.

Based on @randall77's comment, it seems like the new behavior is technically more correct. Did the actual conversion also used to succeed? If so, this might be a breaking change (not saying we should roll it back, but maybe something to be aware of).

Based on @randall77's comment, it seems like the new behavior is technically more correct. Did the actual conversion also used to succeed?

yeah, it did (see the test case), which is really unfortunate

The behavior changed at https://go-review.googlesource.com/c/go/+/309729
Not sure that was intentional.

@jinzhu @ianlancetaylor

@griesemer Am I right, that the new behavior is correct?

If so, this might be a breaking change (not saying we should roll it back, but maybe something to be aware of).

It seems like this a breaking change that is in bounds per https://golang.org/doc/go1compat ("If a compiler or library has a bug that violates the specification, a program that depends on the buggy behavior may break if the bug is fixed. We reserve the right to fix such bugs.")

At the very least this needs to be documented in the release notes, but it's worth asking if the benefits gained by the change outweigh the breakage incurred, or if there is an alternate way to fix the issue https://go-review.googlesource.com/c/go/+/309729 was addressing without breaking existing programs.

It definitely seems like a bug. This code prints false:

package main

import "reflect"

type A struct {
}
type B struct {
}

func main() {
	a := []A{}
	b := []B{}

	println(reflect.ValueOf(a).Type().ConvertibleTo(reflect.ValueOf(b).Type()))
}

In 1.16, ConvertibleTo only reports true if the base types are from two different packages and are identically named. That can't be right.

But I agree, we don't want to break existing programs lightly. We'll have to ponder whether/how to fix this, or document it, or whatever.

As discussed above, this change is correct. The types are not convertible and reflect.ConvertibleTo should not be reporting that they are convertible. This change seems clearly correct.

I agree that this should be in the release notes. It didn't occur to me that this would affect ConvertibleTo and AssignableTo in this way.

It's unfortunate that this breaks existing programs, but the earlier behavior was clearly a bug. The reflect package should not be reporting that types are convertible when they are not convertible in the language.

We actually got the correct answer here in Go releases up to 1.7. It broke in Go 1.8. Looks like the breaking change was https://golang.org/cl/24190.

24190 was just the spec change, the actual breaking CL was https://go-review.googlesource.com/c/go/+/30191

Change https://golang.org/cl/343329 mentions this issue: reflect: add test for invalid conversion

Remilestoned to 1.17 for a doc fix.

Change https://golang.org/cl/343669 mentions this issue: [release-branch.go1.17] doc: mention fix of Convert/ConvertibleTo in 1.17

Change https://golang.org/cl/343690 mentions this issue: _content/doc: mention fix of Convert/ConvertibleTo in 1.17

Change https://golang.org/cl/343669 can be abandoned, as we don't generally keep the release-branch's HTML up to date. The x/website change will correctly update the documentation.