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)
For an interface, you compare two pointers (in the current implementation) etc. "==" is just value comparison everywhere. Everything is a value. On Friday, July 1, 2016 at 2:01:11 AM UTC+2, kortschak wrote: > > This position precludes the following use of the equality operator for > scalar values: > > a := 1 > b := 1 > > a == b would be false under the approach below since a and b are not the > same set of bits. > > I think most people would find this a little surprising. > > On Thu, 2016-06-30 at 09:24 -0700, Chad 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. > > > -- 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.
