On Thu, Jun 30, 2016 at 9:24 AM, Chad <send2b...@gmail.com> wrote:
> It's a view in another array.
> Why should they be equal? Unless the second slice is constructed by
> subslicing the other as such `[:]`, the slices are different.
>
> If I were to access one of the slice backing array and mutate it, I wouldn't
> expect the slices to be equal anymore.
>
> The argument that it would be surprising is perhaps flawed because it stems
> from a misconception.
> A slice is a dynamic view. For two slices to be equal it makes sense to be
> looking at the same thing at all time.
>
> Taken mathematically, if we describe an indirection as a mathematical
> function, a slice is such a function. Two functions are equals if they are
> equals everywhere they are defined. A slice is equal to another slice if the
> backign arrays always have the same values, whatever mutation occurs on any
> of them.
>
> Comparing the snapshot view of a slice would then different. The behaviour
> seems consistent to me.
This discussion is a good example of why the language does not define
the behavior. There are solid arguments on both sides.
Ian
> On Thursday, June 30, 2016 at 4:54:59 PM UTC+2, Paul Borman wrote:
>>
>> It would be very surprising to people to use a slice as a key to map, say
>> []int{1,2} and then find that using another []int{1,2} does not find that
>> entry. While I think it would be nice to have == on slices, I must agree
>> with Ian and authors that it is better left unsaid.
>>
>> -Paul
>>
>> On Thu, Jun 30, 2016 at 1:09 AM, Chad <send...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Thursday, June 30, 2016 at 8:32:58 AM UTC+2, Viktor Kojouharov wrote:
>>>>
>>>> This would probably introduce unnecessary confusion. People are used to
>>>> the equality operator comparing values in go, as opposed to references.
>>>> It's
>>>> much better if the slices finally support the equality operator, even
>>>> though
>>>> the comparison speed will depend on the number of items in the slices.
>>>>>
>>>>>
>>> Well, in fact, everything is a value in Go. It's just that the internal
>>> structure of the standard reference types are not exposed.
>>> The behaviour should not be very different from the comparison between
>>> user defined structs where one or more fields are pointers.
>>>
>>> It also makes sense to say that two slices are equal iff they represent
>>> the exact same views of the exact same underlying array.
>>>
>>>
>>> --
>>> 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.
