On Fri, Jul 1, 2016 at 12:48 PM, Chad <send2b...@gmail.com> wrote:
> On Friday, July 1, 2016 at 12:11:43 PM UTC+2, Martin Geisler wrote:
>>
>> On Fri, Jul 1, 2016 at 3:15 AM, Chad <send...@gmail.com> wrote:
>> > No, it's actually fine. You are comparing values.
>> >
>> > A slice being a struct under the hood, for slices you would compare the
>> > structs (slice headers)
>>
>> Yes, when you remember that a slice is a just a small struct with a
>> pointer and some bookkeeping information (length, capacity), then you
>> can compare two slices easily. So with
>>
>> a := []int{10, 20, 30}
>> b := a[:]
>>
>> then a == b would be fast: simply compare the pointers and the
>> bookkeeping information. Direct value equality between the structs
>> gives you the expected and correct answer.
>>
>> But what about
>>
>> []int{10, 20} == []int{10, 20}
>>
>> where the two slices refer to different underlying arrays? I think you
>> argue that this comparison should be false?
>
>
> Yes. And it is. A slice is not an array. Or an open-ended array.
Right, a slice is just view into an array :-)
I was hinting at the (lack of) symmetry with how strings work.
Two strings that share no underlying memory can compare equal, so I
think it would be reasonable if equality between slices followed the
same principle. Put differently, strings are "magic" and don't follow
normal rules for comparison, in particular, they don't use direct
value comparison. Here I'm assuming that
https://golang.org/pkg/reflect/#StringHeader
shows us how strings are implemented: a small struct with a pointer
and a length. If string comparison were to use value semantics, a and
b could not compare equal in this little example
a := "hello world"
b := make([]byte, len(a))
os.Stdin.Read(b)
since the pointer in a would differ from the pointer in b. Yet a == b
is true when you enter "hello world" :-) So we see the magic slip
through the cracks...
Given that, one could argue that it would be consistent to have
[]int{1} == []int{1} be true -- it's just yet another exception to the
rule that things are compared by value. It's not super pretty, though,
but I my opinion the illusion of prettyness has already been broken
with how some builtin types get special treatment here and there.
--
Martin Geisler
--
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.
