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