Ian, what you say is true, but is also true of types and other objects too,
I think. I found some interesting anomalies playing around with the new
plugin package.

Myself, I would have no objection to saying that two function values are
equal if they are defined by the same source code and use no variables in
outer non-global scopes. But I guess that would preclude certain compiler
optimisations that pull in variables that happen to have known constant
values.

I also wouldn't mind defining closure equality as undefined, but perhaps
best to steer away from more undefined behaviour.

  cheers,
    rog.

On 23 Nov 2016 18:09, "Ian Lance Taylor" <i...@golang.org> wrote:

> On Wed, Nov 23, 2016 at 7:00 AM, T L <tapir....@gmail.com> wrote:
> >
> > On Wednesday, November 23, 2016 at 10:35:59 PM UTC+8, Axel Wagner wrote:
> >>
> >> So, your suggestion is, to have functions be comparable, but have the
> >> comparisons always be false (unless compared to nil)? How would that be
> >> useful and *not* completely confusing? e.g. how would that not lead to
> >> people asking here, once a week, why (os.Open == os.Open) == false or
> >> something like that?
> >
> >
> > No, I don't os.Open != os.Open, they are the same question, so they are
> > equal.
>
> Even this seemingly simple statement is unclear.  Go now supports
> -buildmode=shared and -linkshared, meaning that a Go program can link
> against a set of shared libraries that are themselves written in Go.
> When running in this mode, a function like os.Open can easily appear
> multiple times in a single program image, in different shared
> libraries.  So while `os.Open == os.Open` might reasonably always be
> true, given
>     func F() func(string) (*os.File, error) {
>         return os.Open
>     }
>
> then it is much less clear whether
>
>     F() == os.Open
>
> should be true, as F might be in a shared library and might return a
> pointer to a different instance of os.Open.
>
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to