Hmm, I suppose I imagined having read a deeper reason than syntax :/. That does seem like an incredibly shallow reason to introduce a whole new non-orthogonal concept (I see others have attempted to tackle the syntax issue, including yourself).
There are actually deeper difficulties than syntax with using interfaces to capture the built-in operators, in that some of them have semantics that can't be captured as methods. One approach is to only use interfaces to describe "well-behaved" operators, leaving the rest as special constructs that can't be abstracted over, like today. But `==` falls into this category, since it works on both pointers and structs, and does different things -- whereas it is not generally possible for a method M to do different things for type T vs type *T. The design I sketched actually just punts on operators entirely, which I don't like but I think is better than where contracts put us (esp. since you still can't actually define alternative notions of `<` with contracts, just abstract over existing ones, so it doesn't even give you much extra expressive power)`. I'd like to find a good solution to the operator problem though. -- 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.
