On Mon, May 2, 2022 at 11:32 PM Will Faught <will.fau...@gmail.com> wrote:
>>
>> There are cases involving closures, generated trampolines, late
>> binding and other details that mean that doing this will either
>> eliminate many optimization possibilities or restrict the compiler too
>> much or cause surprising results. We disabled function comparison for
>> just these reasons. It used to work this way, but made closures
>> surprising, so we backed out and allow comparison only to nil.
>
>
> That's interesting. I didn't know that. :)
>
> When I run:
>
> ```
> func f() {
> x := func() {}
> y := func() {}
> fmt.Printf("%#v %#v %#v %#v\n", x, y, func() {}, func() {})
> }
>
> func g() {}
>
> func main() {
> fmt.Printf("%#v %#v %#v %#v\n", f, g, func() {}, func() {})
> f()
> }
> ```
>
> I get:
>
> ```
> (func())(0x108ac80) (func())(0x108ad40) (func())(0x108ad60)
> (func())(0x108ad80)
> (func())(0x108ac00) (func())(0x108ac20) (func())(0x108ac40)
> (func())(0x108ac60)
> ```
>
> I don't know where those integer values are coming from, but those are what I
> meant by memory addresses. They seem to be unique per function value. Can't
> the runtime calculate those same values for comparisons?
Yes, it can. That's not the issue. The issue is that whether those
pointer values are equal for two func values is not intuitive at the
language level. When using shared libraries (-buildmode=shared) you
can get two different pointer values for references to the same
function. When using method values you can get the same pointer value
for references to method values of different expressions of the same
type. When using closures you will sometimes get the same value,
sometimes different values, depending on the implementation and the
escape analysis done by the compiler.
> The point isn't to provide equivalence operations; it's to provide useful
> comparison operations that are consistent with the other types' comparison
> operations, to make all types consistent and simplify the language. We could
> provide a separate equivalence operation, perhaps something like `===` that
> behaves like `reflect.DeepEquals`, but that's a separate issue. Shallow slice
> comparisons do allow you to conclude that elements are equal if slices
> compare equal, and we can still iterate slices manually to compare elements.
It's important that Go operators be intuitive for programmers. For
example, many new Java programmers find that the == operator for
strings is not intuitive in Java. What is people's intuition for
slice equality? I think that different people make different
assumptions. Not supporting the == operators ensures that nobody gets
confused.
Ian
--
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/CAOyqgcWA_BrtMmhZTQUWgEDYKAUOjZ7LW41qLBfUY8oNbLW4uw%40mail.gmail.com.
