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 <javascript:>>
> 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.
I would hope that slices from different underlying arrays could be
> compared for equality based on their values, just like strings can.
> Two strings (that are not slices from the same original string) can be
> compared for equality just fine. I hope Go takes the shortcut when the
> strings refer to the same memory and otherwise does the slower
> per-byte comparison. The same could perhaps apply to slices in
> general.
>
> strings are immutable. They are more akin to an array of bytes than a
slice of bytes.
> --
> 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.
