Here’s a draft for a Go 2 proposal that I’d like to add to the issue tracker since there’s no discussion there about this:
Slices should have equality defined. https://golang.org/doc/faq#map_keys Map lookup requires an equality operator, which slices do not implement. > They don't implement equality because equality is not well defined on such > types; there are multiple considerations involving shallow vs. deep > comparison, pointer vs. value comparison, how to deal with recursive types, > and so on. This proposal allows slices to be used as map keys and for comparison with == and !=. https://golang.org/ref/spec#Comparison_operators Slice, map, and function values are not comparable. An initial proposal is that slices are compared by nil versus non-nil, length and backing array pointer, and then by the rules for array if length is equal but different arrays are pointed: Array values are comparable if values of the array element type are > comparable. Two array values are equal if their corresponding elements are > equal. reflect.DeepEqual defines a similar slice equality except “deeply equal” defines additional criteria: https://golang.org/pkg/reflect/#DeepEqual Slice values are deeply equal when all of the following are true: they are > both nil or both non-nil, they have the same length, and either they point > to the same initial entry of the same underlying array (that is, &x[0] == > &y[0]) or their corresponding elements (up to length) are deeply equal. > Note that a non-nil empty slice and a nil slice (for example, []byte{} and > []byte(nil)) are not deeply equal. A use case for me was a map keyed by varying length paths where the map was not shared between different path generating computations. With this proposal such a type could have shared generated paths as keys. Ian suggests in a [this] golang-nuts thread that there are varying use cases: The problem is that different programs need different things for slice > equality. Some want pointer equality as you suggest. Some want element > comparisons, as is done for array equality. Without an obvious semantics > for the operation, the language omits it entirely. > But I don’t know where slice pointer equality would be useful. I'm also not clear on the recursive type problem. Matt On Monday, July 4, 2016 at 2:29:18 AM UTC-5, Chad wrote: > > I realize that the issue might be about changing/ adding a builtin: > > - either add a builtin deep value Comparison function (via reflection) > - or add a snapshot type refinement which triggers the allocation of > an immutable copy of a reference type > (and we would recover the behaviour of the string implementation which > is a special case of []byte snapshot, i.e. a value type*) > > I would still expect the behaviour previously mentioned for the "==" > operator. > > (*) I keep using reference/value type terminology but it is indeed > slightly tricky. But for lack of a better one... > -- 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.
