Kurtis, Thing is an interface in the first example I gave:
If you want to compare two interfaces: var foo1 Thing var foo2 Thing Ordinarily you can do foo1 == foo2 and it does pointer-wise comparison. This absolutely is the case: https://gotipplay.golang.org/p/ODG9xvyVEqs Now, I understand the confusion because I did have a major typo in the second part of the question; But in a generic function, as an example: // IsEmpty checks if the interface is equal to nil. func IsEmpty[T Block](blk T) bool { var empty T return empty == blk } (I had blk Block before, instead of blk T). Comparing with empty is something I've needed to do a bunch of times and have been unable to do. On Wed, Jan 18, 2023 at 5:40 PM Kurtis Rader <kra...@skepticism.us> wrote: > > On Wed, Jan 18, 2023 at 5:14 PM 'Christian Stewart' via golang-nuts > <golang-nuts@googlegroups.com> wrote: >> >> The thing I ran into with this today was, if you want to compare two >> interfaces: >> >> var foo1 Thing >> var foo2 Thing >> >> Ordinarily you can do foo1 == foo2 and it does pointer-wise comparison. > > > No, it does not. Consider the following example. Do all three vars have the > same address? > > package main > > type Thing struct{} > > var foo1 Thing > > func main() { > var foo2 Thing > var foo3 Thing > println(foo1 == foo2, &foo1, &foo2) > println(foo2 == foo3, &foo2, &foo3) > } > > The output will probably surprise you. See > https://go.dev/ref/spec#Comparison_operators. An empty struct is handled > thusly: > > Struct values are comparable if all their fields are comparable. Two struct > values are equal if their corresponding non-blank fields are equal. > > Obviously, depending on how "Thing" is defined the results may be different. > Perhaps you are thinking of the case where "Thing" is an interface. > >> But in a generic function, as an example: >> >> // IsEmpty checks if the interface is equal to nil. >> func IsEmpty[T Block](blk Block) bool { >> var empty T >> return empty == blk >> } >> >> ... that doesn't work due to the errors mentioned in this thread. And >> I can't make the type constraint comparable either, that doesn't seem >> to work. >> >> On Wed, Jan 18, 2023 at 4:59 PM burak serdar <bser...@computer.org> wrote: >> > >> > >> > >> > On Wed, Jan 18, 2023 at 5:52 PM Andrew Athan <andrew...@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+unsubscr...@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. >> > >> > -- >> > 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/CAMV2Rqo_nrhZfvJ_9qykTkg%3DTxbgdZMC7zFHx1rNnGcdgQk8cA%40mail.gmail.com. >> >> -- >> 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/CA%2Bh8R2pDwa0ygGvcZwV-2aa3zhtVqZoZ9YPiFRFmBmF7JsKzqg%40mail.gmail.com. > > > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank -- 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/CA%2Bh8R2rQ9COyYTW%2BcU3NEU%2BRwQ%2BQDy0c%2BFrwc_kHVFLvJiR8mg%40mail.gmail.com.
