I'd rather people were given a correct simple explanation rather than
foregoing any explanation because it may appear complex at first sight.
Especially since it alters how maps can be used, later on. (the hashing
algorithm relies on comparability).
On Thursday, June 30, 2016 at 10:32:58 PM UTC+2, Jakob Borg wrote:
>
> 2016-06-30 22:23 GMT+02:00 Chad <send...@gmail.com <javascript:>>:
> >> Your proposition merely moves the semantical constraint to another
> >> place: as Ian pointed out, if we define equality for slices to be
> >> something resembling pointer equality suddenly []byte{1, 2} is not
> equal
> >> to []byte{1, 2}.
> >
> >
> > They are not since creating a slice allocate a different underlying
> array
> > each time. They are not views on the same array.
> > It is merely incidental that on the example that is given, the two
> arrays
> > have the same first and second elements.
>
> This may seem entirely obvious to you, but explaining to a newcomer why
>
> fmt.Println(1 == 1) // => true
> fmt.Println("2" == "2") // => true
> fmt.Println([...]int{1, 2} == [...]int{1, 2}) // => true
> fmt.Println([]int{1, 2} == []int{1, 2}) // => false
is not something I feel would make the language better.
> //jb
>
One way to go about this would be to put more emphasis on the concept of
reference type in the documentation and introduce this behaviour as the
main divergence from pure value types. But that wouldn't be the most
complex thing to learn.
--
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.
