I was only pointing out that if you use method based operations you can do whatever comparisons you find appropriate.
> On May 4, 2022, at 8:19 PM, Will Faught <will.fau...@gmail.com> wrote: > > > I don't follow how that's related to slice comparisons, aside from that fact > that slice comparison could be a method, but an Equals() method would be left > out to be consistent with how it is today. > >> On Wed, May 4, 2022 at 5:22 AM Robert Engels <reng...@ix.netcom.com> wrote: >> Seems easier to move to a Go without operators and do everything with >> functions and generics. This is essentially the Java model. >> >> This is pretty much the approach that the sync, sort, etc packages took and >> with generics you can have type safety and less code duplication. >> >>>> On May 4, 2022, at 1:49 AM, Will Faught <will.fau...@gmail.com> wrote: >>>> >>> >>> Well, I agree! :) Comparisons should be shallow where possible for every >>> type, including slices and maps. That's my initial argument. >>> >>>> On Tue, May 3, 2022 at 11:22 PM Jan Mercl <0xj...@gmail.com> wrote: >>>> On Wed, May 4, 2022 at 12:15 AM Will Faught <will.fau...@gmail.com> wrote: >>>> >>>> > I'm not sure we're on the same page in terminology. I meant shallow as >>>> > opposed to deep. E.g. pointer equality in terms of `==` vs. >>>> > `reflect.DeepEqual`. Unequal pointers can reference values that are >>>> > equivalent. >>>> >>>> I think we are on the same page. This thread is about comparisons on >>>> the language level, not about some library functions. Thus we can >>>> ignore reflect.DeepEqual and focus on the equality operator only. That >>>> makes things simpler. >>>> >>>> Now, what I wanted to point out is that the equality operator, as >>>> defined in Go, always compares the values of its operands. It's a >>>> simple and easy to remember rule. It could have been defined in a >>>> different way, sure. Anyway, it was not and talking about deep vs >>>> shallow comparison of the Go equality operator does not make the >>>> discussion any clearer - because it does not, in our case, apply. >>> >>> -- >>> 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/CAKbcuKjr2AKu07hWfPxZLoKoNO5EMbZb8HGgRMOHULDh6Yd5iQ%40mail.gmail.com. > > -- > 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/CAKbcuKhSCJV8Xb9Zehtfh1yLuWX1PYd6yFdiBpqAbM-PT%2BakAw%40mail.gmail.com. -- 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/FCDEB1DA-7D84-4AEF-AAE5-8D94159ABE26%40ix.netcom.com.
