The string in the method is a type parameter. The whole method declaration body is equivalent to

func (s *Set[T]) String() T {
	keys := make([]T, 0, len(*s))
	for k := range *s {
		keys = append(keys, k)
	}
	sort.Strings(keys)             // cannot use keys (variable of type []T) as []string value in argument to sort.Strings (!!!)
	return strings.Join(keys, ",") // cannot use keys (variable of type []T) as []string value in argument to strings.Join (!!!)
}

Yes I realized as much after scratching my head and asking for help, but that doesn't make the compiler message helpful as it is

Please see https://go.dev/doc/faq#types_in_method_declaration .

But, yes, perhaps the compiler can give a better error message if the error has two different types with the same name.

CC @griesemer

Thanks!

Someone suggested to use [type] instead of type for that error / generic type names, that would have given me a better hint (though []comparable would have been even better)

Agreed that the compiler should do a better job in cases like these.

@ldemailly FWIW I don't think that using [T] instead of T for type parameters would be a good fix, as you get the same problem if you do type string int. Though arguably that would be less confusing, as it is less obvious that the type parameter name introduces a new type, while type string int is pretty abundantly clear. Either way, I also don't think it's obvious that [T] refers to a type parameter and [][string] most definitely looks confusing.

IMO it would be a better fix if the compiler would say something like can't use []string (with string definde in foo.go:42:23) as []string (with string predeclared) or something, if the stringified type names are equal. No idea how complex that'll be. I'm sure someone can figure something out that's clear.

Change https://go.dev/cl/470075 mentions this issue: go/types, types2: point out type parameters with predeclared names in errors

Thx for super quick fix! one question though, I am not super clear from the mr what the new error message looks like?

For the program in the playground it will now report:

./x.go:15:15: cannot use keys (variable of type []string /* with string declared at ./x.go:10:14 */) as []string value in argument to sort.Strings
./x.go:16:9: cannot use strings.Join(keys, ",") (value of type string) as string /* with string declared at ./x.go:10:14 */ value in return statement
./x.go:16:22: cannot use keys (variable of type []string /* with string declared at ./x.go:10:14 */) as []string value in argument to strings.Join

It's not the most beautiful error message but it hopefully makes it clear which of the string types is user-defined. This is a rare case, after all, and pointing out that something unusual is happening should help a lot.

More generally, whenever a type parameter name matches a name of a predeclared type or object (even true or false) we get the special annotation. Again, usually programs won't use names of predeclared objects in situations like these.

(The new error message should actually be present in the dev playground, but it doesn't appear to be up-to-date at the moment.)