Quoting Eric Raymond (2018-10-15 22:24:50) > The simplest and most effective way to solve the generics problem is to > embrace operator overloading and the kind of magic method designations > that go with it.
This matches my intuition as well, though see below. > Can it even possibly be simpler than this? What, if anything, am I > missing? There are a couple of things I could bikeshed, but instead I'll raise a deeper problem, which none of the operator-overloading designs I've seen (or thought of) have had an answer for, and I think *needs* to be solved for this to work: The semantics of `==` in Go cannot be understood as a method or function. In particular, there is a restriction in the go spec that says you can't implement methods with the same name on both T and *T. However, `==` is defined on pointers, and always computes pointer identity, whereas it may (almost certainly will) do something different on the type that the pointer points to. There are other operators in the language that don't behave like functions or methods (e.g. boolean operators like && and ||, which short-circut), but the rest of them are things that don't have gobs of use cases for overriding anyway, so it's easy to just say "you can't override those." I don't think we can credibly call operator overloading a solution if you can't abstract over ==. Breaking backwards compatibility opens up some options, but I still haven't been able to come up with a solution that has a credible upgrade path. I've mentioned this when it's come up in a couple of other threads, but not everybody reads every rabbit-hole conversation about generics... -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. For more options, visit https://groups.google.com/d/optout.
