Quoting Eric Raymond (2018-10-15 23:32:22) > Fair enough. I am completely willing to discard the possibility of > overloading && and || and almost any other operator that doesn't behave > like a function, because I think we get a rich enough set of contracts > from those that do. As I implied in my proposal, I think what people > really want from contacts is relationals and some operator algebra.
+1. == is the sticking point. > That is to forbid "implements" methods on pointer types at compile > time. The other bit of this, that I think is worth making explicit is that normally If you have a method on a type T, you can also call that method on a value of type *T. For this to work you'd also have to have == be an exception to that rule, where == on a type of the form *T is always pointer equality, regardless of what == means on T. I'm not in love with the inconsistency, and expect it to cause some confusion with newbies, but I'd have to use it to see how big of a footgun it is in practice. There are certainly worse ideas. > I can't think of a use case for such overloads that isn't overly clever > to the point of crazy. I am more than willing to chop that off to preserve > the simplicity and transparency of the cases where "implements" is legal. Agree, my only concern is as mentioned above. It's also worth noting that you can always wrap the pointer in a new type if you want to define operators on it. -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.
