Are there many instances where interpretation (1) is useful? I would also observe: if Go implemented case (2) for "==", this doesn't prevent the user from implementing case (1) using a separate function, as today.
Supplementary question: does the Go standard library even expose a function for case (1), or would you have to do it yourself using e.g. unsafe.SliceData? Clearly case (2) is supported via bytes.Equal, slices.Equal etc. On Sunday 11 August 2024 at 05:08:26 UTC+6 Ian Lance Taylor wrote: > On Fri, Aug 9, 2024 at 9:03 PM 'Brian Candler' via golang-nuts > <golan...@googlegroups.com> wrote: > > > > I would agree, except there is no == operator defined on slices, and I'm > not really sure why that is. The semantics I would expect are > straightforward: i.e. length is the same, and the first 'len' slice > elements compare as equal, recursively if necessary. (*) > > There is no == operator on slice types because there are two possible > meanings: > 1) Two slices are equal if they have the same length and refer to the > same underlying array. > 2) Two slices are equal if they have the same length and each > individual element is itself equal. > > Because it's not clear which definition of equality people might mean, > the language doesn't define ==, and forces people to choose which > definition they want in any given situation. > > Ian > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/62959bba-5170-4f1a-b8b4-f023a22848cen%40googlegroups.com.
