Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

[Ian Lance Taylor]

On Thu, Nov 24, 2016 at 6:01 AM, T L  wrote:
>
> On Thursday, November 24, 2016 at 8:16:49 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Wed, Nov 23, 2016 at 3:49 PM, roger peppe  wrote:
>> > 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.
>>
>> We've worked hard to make sure that what I said earlier is not true of
>> types, even in the presence of shared libraries.  If we've failed,
>> please file bugs.  Even with plugins it should work correctly.
>
>
> so os.File from a plugin is the same as the os.File in the host program?
> how do we know the os package from a plugin is the same package in the host
> program?

In a Go program, the path used in the import statement uniquely
defines a package.  If you write a plugin that breaks that rule, your
plugin will not work correctly.

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.

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

[T L]

On Thursday, November 24, 2016 at 8:16:49 AM UTC+8, Ian Lance Taylor wrote:
>
> On Wed, Nov 23, 2016 at 3:49 PM, roger peppe  > wrote: 
> > 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. 
>
> We've worked hard to make sure that what I said earlier is not true of 
> types, even in the presence of shared libraries.  If we've failed, 
> please file bugs.  Even with plugins it should work correctly. 
>
> Ian 
>

so os.File from a plugin is the same as the os.File in the host program?
how do we know the os package from a plugin is the same package in the host 
program?

 

-- 
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.

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

[T L]

On Thursday, November 24, 2016 at 1:30:55 AM UTC+8, Axel Wagner wrote:
>
> On Wed, Nov 23, 2016 at 4:30 PM, T L  
> wrote:
>
>> If two functions do completely different things, they mus be two 
>> different functions.
>>
>
> No. An example has been given above, here is another one:
> https://play.golang.org/p/uNN0G4gzFm
>  
>
>> Two different functions can also do the same thing, but they should be 
>> not equal.
>>
>
> Why not? If someone who never read go code reads "f == g", why would they 
> assume that this is your definition? Why wouldn't they get confused, that 
> two functions who have the same definition (not "stem from the same 
> declaration", but "contain the same code") are not equal?
>
> I agree that your definition is *consistent*. But it is still a) confusing 
> for some cases and b) *not obviously the only sensible one*. Meaning, 
> newcomers won't be able to infer from the expression, what it does. At all.
> (yes, go has similar problems elsewhere. But that doesn't mean, that we 
> should pile on)
>

Then, how about let functions come from the same one function literal be 
equal? 
 

>  
>
>>  
>>
>>>
>>> Can you give a good justification of that behavior? And do you really 
>>> think it won't confuse people like hell?
>>>
>>> One of the main reasons given for not making functions comparable, is 
>>> that there is no good, intuitive notion of what "equality" means in the 
>>> face of inlining and closures, so *no matter what behavior you choose*, 
>>> people will be confused.
>>>
>>> On Wed, Nov 23, 2016 at 4:01 PM, T L  wrote:
>>>


 On Wednesday, November 23, 2016 at 10:39:01 PM UTC+8, Volker Dobler 
 wrote:
>
> Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L:
>>
>>
>>
>> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler 
>> wrote:
>>>
>>> Just one argument out of many: Closures.
>>> x := 3
>>> f1 := func() int {
>>> return x
>>> }
>>> f2 := func() int { return 3 }
>>> // Is f1 == f2 ?
>>>
>>> x = 4
>>> // What now? Still f1 == f2? Or never equal?
>>>
>>>
>> Any bad to think then never equal?
>>
>
> That's basically is it: If functions are never equal so it is
> not sensible make them comparable.
>
> V.
>

 functions from the same declaration are equal.
 and function variables at the same address are equal.
  

 -- 
 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.
 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...@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.

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

[Ian Lance Taylor]

On Wed, Nov 23, 2016 at 3:49 PM, roger peppe  wrote:
> 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.

We've worked hard to make sure that what I said earlier is not true of
types, even in the presence of shared libraries.  If we've failed,
please file bugs.  Even with plugins it should work correctly.

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.

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

[roger peppe]

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"  wrote:

> On Wed, Nov 23, 2016 at 7:00 AM, T L  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.

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

[Ian Lance Taylor]

On Wed, Nov 23, 2016 at 7:00 AM, T L  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.

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

['Axel Wagner' via golang-nuts]

(note: I'm exiting this thread now. I believe at this point it's reasonably
clear, that there are good reasons for this and anyone not convinced yet
won't be convinced by further arguments anyway)

On Wed, Nov 23, 2016 at 6:30 PM, Axel Wagner 
wrote:

> On Wed, Nov 23, 2016 at 4:30 PM, T L  wrote:
>
>> If two functions do completely different things, they mus be two
>> different functions.
>>
>
> No. An example has been given above, here is another one:
> https://play.golang.org/p/uNN0G4gzFm
>
>
>> Two different functions can also do the same thing, but they should be
>> not equal.
>>
>
> Why not? If someone who never read go code reads "f == g", why would they
> assume that this is your definition? Why wouldn't they get confused, that
> two functions who have the same definition (not "stem from the same
> declaration", but "contain the same code") are not equal?
>
> I agree that your definition is *consistent*. But it is still a) confusing
> for some cases and b) *not obviously the only sensible one*. Meaning,
> newcomers won't be able to infer from the expression, what it does. At all.
> (yes, go has similar problems elsewhere. But that doesn't mean, that we
> should pile on)
>
>
>>
>>
>>>
>>> Can you give a good justification of that behavior? And do you really
>>> think it won't confuse people like hell?
>>>
>>> One of the main reasons given for not making functions comparable, is
>>> that there is no good, intuitive notion of what "equality" means in the
>>> face of inlining and closures, so *no matter what behavior you choose*,
>>> people will be confused.
>>>
>>> On Wed, Nov 23, 2016 at 4:01 PM, T L  wrote:
>>>


 On Wednesday, November 23, 2016 at 10:39:01 PM UTC+8, Volker Dobler
 wrote:
>
> Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L:
>>
>>
>>
>> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler
>> wrote:
>>>
>>> Just one argument out of many: Closures.
>>> x := 3
>>> f1 := func() int {
>>> return x
>>> }
>>> f2 := func() int { return 3 }
>>> // Is f1 == f2 ?
>>>
>>> x = 4
>>> // What now? Still f1 == f2? Or never equal?
>>>
>>>
>> Any bad to think then never equal?
>>
>
> That's basically is it: If functions are never equal so it is
> not sensible make them comparable.
>
> V.
>

 functions from the same declaration are equal.
 and function variables at the same address are equal.


 --
 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.
 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.
>>
>
>

-- 
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.

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

['Axel Wagner' via golang-nuts]

On Wed, Nov 23, 2016 at 4:30 PM, T L  wrote:

> If two functions do completely different things, they mus be two different
> functions.
>

No. An example has been given above, here is another one:
https://play.golang.org/p/uNN0G4gzFm


> Two different functions can also do the same thing, but they should be not
> equal.
>

Why not? If someone who never read go code reads "f == g", why would they
assume that this is your definition? Why wouldn't they get confused, that
two functions who have the same definition (not "stem from the same
declaration", but "contain the same code") are not equal?

I agree that your definition is *consistent*. But it is still a) confusing
for some cases and b) *not obviously the only sensible one*. Meaning,
newcomers won't be able to infer from the expression, what it does. At all.
(yes, go has similar problems elsewhere. But that doesn't mean, that we
should pile on)


>
>
>>
>> Can you give a good justification of that behavior? And do you really
>> think it won't confuse people like hell?
>>
>> One of the main reasons given for not making functions comparable, is
>> that there is no good, intuitive notion of what "equality" means in the
>> face of inlining and closures, so *no matter what behavior you choose*,
>> people will be confused.
>>
>> On Wed, Nov 23, 2016 at 4:01 PM, T L  wrote:
>>
>>>
>>>
>>> On Wednesday, November 23, 2016 at 10:39:01 PM UTC+8, Volker Dobler
>>> wrote:

 Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L:
>
>
>
> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler
> wrote:
>>
>> Just one argument out of many: Closures.
>> x := 3
>> f1 := func() int {
>> return x
>> }
>> f2 := func() int { return 3 }
>> // Is f1 == f2 ?
>>
>> x = 4
>> // What now? Still f1 == f2? Or never equal?
>>
>>
> Any bad to think then never equal?
>

 That's basically is it: If functions are never equal so it is
 not sensible make them comparable.

 V.

>>>
>>> functions from the same declaration are equal.
>>> and function variables at the same address are equal.
>>>
>>>
>>> --
>>> 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.
>>> 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.
>

-- 
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.

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

[T L]

On Wednesday, November 23, 2016 at 11:11:24 PM UTC+8, Axel Wagner wrote:
>
> So, even though two functions do completely different things, you still 
> want to have them equal? And even though two other functions do completely 
> the same thing, they should be different?
>

If two functions do completely different things, they mus be two different 
functions.
Two different functions can also do the same thing, but they should be not 
equal.
 

>
> Can you give a good justification of that behavior? And do you really 
> think it won't confuse people like hell?
>
> One of the main reasons given for not making functions comparable, is that 
> there is no good, intuitive notion of what "equality" means in the face of 
> inlining and closures, so *no matter what behavior you choose*, people will 
> be confused.
>
> On Wed, Nov 23, 2016 at 4:01 PM, T L  
> wrote:
>
>>
>>
>> On Wednesday, November 23, 2016 at 10:39:01 PM UTC+8, Volker Dobler wrote:
>>>
>>> Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L:



 On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler 
 wrote:
>
> Just one argument out of many: Closures.
> x := 3
> f1 := func() int {
> return x
> }
> f2 := func() int { return 3 }
> // Is f1 == f2 ?
>
> x = 4
> // What now? Still f1 == f2? Or never equal?
>
>
 Any bad to think then never equal?

>>>
>>> That's basically is it: If functions are never equal so it is
>>> not sensible make them comparable.
>>>
>>> V.
>>>
>>
>> functions from the same declaration are equal.
>> and function variables at the same address are equal.
>>  
>>
>> -- 
>> 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 .
>> 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.

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

['Axel Wagner' via golang-nuts]

So, even though two functions do completely different things, you still
want to have them equal? And even though two other functions do completely
the same thing, they should be different?

Can you give a good justification of that behavior? And do you really think
it won't confuse people like hell?

One of the main reasons given for not making functions comparable, is that
there is no good, intuitive notion of what "equality" means in the face of
inlining and closures, so *no matter what behavior you choose*, people will
be confused.

On Wed, Nov 23, 2016 at 4:01 PM, T L  wrote:

>
>
> On Wednesday, November 23, 2016 at 10:39:01 PM UTC+8, Volker Dobler wrote:
>>
>> Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L:
>>>
>>>
>>>
>>> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler wrote:

 Just one argument out of many: Closures.
 x := 3
 f1 := func() int {
 return x
 }
 f2 := func() int { return 3 }
 // Is f1 == f2 ?

 x = 4
 // What now? Still f1 == f2? Or never equal?


>>> Any bad to think then never equal?
>>>
>>
>> That's basically is it: If functions are never equal so it is
>> not sensible make them comparable.
>>
>> V.
>>
>
> functions from the same declaration are equal.
> and function variables at the same address are equal.
>
>
> --
> 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.

[go-nuts] Re: Why doens't function type support comparision but channel type does?

[T L]

On Wednesday, November 23, 2016 at 10:39:01 PM UTC+8, Volker Dobler wrote:
>
> Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L:
>>
>>
>>
>> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler wrote:
>>>
>>> Just one argument out of many: Closures.
>>> x := 3
>>> f1 := func() int {
>>> return x
>>> }
>>> f2 := func() int { return 3 }
>>> // Is f1 == f2 ?
>>>
>>> x = 4
>>> // What now? Still f1 == f2? Or never equal?
>>>
>>>
>> Any bad to think then never equal?
>>
>
> That's basically is it: If functions are never equal so it is
> not sensible make them comparable.
>
> V.
>

functions from the same declaration are equal.
and function variables at the same address are equal.
 

-- 
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.

Re: [go-nuts] Re: Why doens't function type support comparision but channel type does?

[T L]

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. 
I just mean comparing different functions always returns false.
 

>
> On Wed, Nov 23, 2016 at 3:30 PM, T L  
> wrote:
>
>>
>>
>> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler wrote:
>>>
>>> Just one argument out of many: Closures.
>>> x := 3
>>> f1 := func() int {
>>> return x
>>> }
>>> f2 := func() int { return 3 }
>>> // Is f1 == f2 ?
>>>
>>> x = 4
>>> // What now? Still f1 == f2? Or never equal?
>>>
>>>
>> Any bad to think then never equal?
>>
>>  
>>
>>> V.
>>>
>>> -- 
>> 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 .
>> 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.

[go-nuts] Re: Why doens't function type support comparision but channel type does?

[Volker Dobler]

Am Mittwoch, 23. November 2016 15:30:39 UTC+1 schrieb T L:
>
>
>
> On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler wrote:
>>
>> Just one argument out of many: Closures.
>> x := 3
>> f1 := func() int {
>> return x
>> }
>> f2 := func() int { return 3 }
>> // Is f1 == f2 ?
>>
>> x = 4
>> // What now? Still f1 == f2? Or never equal?
>>
>>
> Any bad to think then never equal?
>

That's basically is it: If functions are never equal so it is
not sensible make them comparable.

V.

-- 
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.

[go-nuts] Re: Why doens't function type support comparision but channel type does?

[T L]

On Wednesday, November 23, 2016 at 9:53:57 PM UTC+8, Volker Dobler wrote:
>
> Just one argument out of many: Closures.
> x := 3
> f1 := func() int {
> return x
> }
> f2 := func() int { return 3 }
> // Is f1 == f2 ?
>
> x = 4
> // What now? Still f1 == f2? Or never equal?
>
>
Any bad to think then never equal?

 

> V.
>
>

-- 
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.

[go-nuts] Re: Why doens't function type support comparision but channel type does?

[Volker Dobler]

Just one argument out of many: Closures.
x := 3
f1 := func() int {
return x
}
f2 := func() int { return 3 }
// Is f1 == f2 ?

x = 4
// What now? Still f1 == f2? Or never equal?

V.

-- 
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.