On Tuesday, October 16, 2018 at 4:41:53 PM UTC-4, Dave MacFarlane wrote: > > Now I'm confused about what problem regarding generics you're trying > to solve with operator overloading. If you can't assume anything about > the meaning of an operator other than "it returns a bool", how could a > programmer use them in a generic contract? Or were you suggesting > operator overloading *instead of* contracts that exist in the current > proposal? (Even in that case, how would a programmer use them in a > generic function without their meaning being well defined?) >
Reviewing this thread, I find your confusion quite reasonable. So let me lay out my philosophical assumptions more carefully. An "implements <" clause would have two different kinds of meaning. One is mechanical and the only kind the compiler knows about. It declares a rewrite rule that means "when you encounter a < between to instances of type T, rewrite it as a call to the the implements method of T if one exists, otherwise throw a compile-time error". The other kind of meaning is unknown to the compiler but shared by humans and library functions. It is an implied semantics something like "this is a predicate testing the most natural ordering of whatever type implements it". The utility of tying contracts to overloading is that we have a well-defined set of expectations about the *semantics* of various operators based on how they behave on primitive types. But the compiler does not and need not know about these expectations; they're expressed as conventions like "don't play stupid and overload < with a method that isn't anticommutative". Or "don't overload + with a noncommutative operation". The motivation for my proposal is that I think 90% of what people want to want a contract system for can be expressed by conventions about what kinds of actual method you bind under a particular operator. I agree that "a << os.Stdout" would be an ugly mistake, but it's not the compiler's job to enforce what can really only be made normative by a healthy culture surrounding the language. (Also, does this mean the compiler wouldn't be able to make any > optimization assumptions regarding whether an operation is > commutative/associative/distributive?) > How does trying to make such assumptions gain anything when the operator compiles to a method call? Serious question; I'm not seeing it. -- 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.
