Thank you for the practical tip on how to avoid the error. The wording of the error could be improved, IMHO, and there is a remaining issue I raised which is not addressed by the suggestion to use the "comparable" constraint (btw, the documentation I've so far been served up by duckduckgo when looking for info on generics is way too introductory, and makes no mention of things like 'comparable').
The remaining issue is that, irrespective of the "wideness" of the "any" type constraint, which apparently includes non-comparable types, the resolution of v's type is to a comparable type, yet the error is still emitted. By the way, this is a classic case of seeing what you want to see ... my near vision is worsening and I read "comparable" in the error message as "compatible," which is at least in part why I found the error message so confusing. v==v, after all, involves two variables of the exact same type by definition :) A. On Wednesday, January 18, 2023 at 4:59:51 PM UTC-8 bse...@computer.org wrote: > On Wed, Jan 18, 2023 at 5:52 PM Andrew Athan <andr...@gmail.com> wrote: > >> (Possibly related to issues such as those discussed in >> https://groups.google.com/g/golang-nuts/c/pO2sclKEoQs/m/5JYjveKgCQAJ ?) >> >> If I do: >> >> ``` >> func Foo[V any](v V)bool { >> return v==v >> } >> ``` >> >> golang 1.19 reports: >> >> ``` >> invalid operation: v == v (incomparable types in type set) >> ``` >> >> There are two issues with this in my mind: (1) It is ambiguous in that I >> cannot be sure, as a new user, whether what's being indicated is an >> incompatibility between the actual types on either side of the equality >> test or between the set of possible types that COULD be on either side of >> the equality test due to V's any type constraing in either the case where >> the left and right side are same or different types (2) In this case, the >> type V appears to be determinable at compile time and yet it is claimed >> this equality test is in some way problematic. >> >> I'm sure I'm misunderstanding something about golang generics. >> >> Can someone comment on this? >> >> Thanks in advance :) >> > > > The problem here is that a type constraint is different from a type, but > the same identifier is overloaded in the language so "any" as a type > constraint means something else from "any" as a type. > > The error is there, because without that Foo([]string{}) would satisfy the > constraint but it is still a compile error. Foo[V comparable)(v V) bool is > the correct declaration. > > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/7134400e-ed5e-4c9f-bacd-4b739daf0e0bn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/7134400e-ed5e-4c9f-bacd-4b739daf0e0bn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9067ad89-957c-4445-87b9-de9517f83052n%40googlegroups.com.
