I think Ian Denhardt is right to argue that fear of operator overloading is driving people in the generics debate to complicated, ugly workarounds that should not be.
I myself do not actually want overloading as a surface feature of the language. In my original "implements" proposal, I accepted it as an implication of using operators to define type classes, because I thought (and still think) it is the simplest possible way to declare contracts. I think the simplicity of having "implements" as the only contract declaration is too important a win to mortgage to a feature many - including myself - are not actually friendly to. Therefore, as the author of the "implements" proposal, I am declaring neutrality on whether an "implements" clause should declare an overload at all! That is, there is a possible future in which "implements <" on type T does not make a < b legal on non-primitive type T, but is solely a typeclass declaration associating T with all other types that implement <; semantically, a Sortable contract. I would be OK with that future, It keeps the important part of "implements" - simplest way to declare contracts - while tossing out the part that (not without reason) raise some hackles. My only caution here is on interface psychology. If we're going to go this route, users are, to be honest. probably going to bitch that not taking the tiny additional step to overloading is perverse. We'll need a good strong public argument to counter that. -- 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.
