On Tue, Oct 16, 2018 at 4:14 PM Eric Raymond <e...@thyrsus.com> wrote: > If the alternative is requiring programmers to remember pre-cooked > relationships between different operators that may or may not be appropriate > for what he or she is trying to model, then I embrace this "problem". > > It's up to the programmer to implement things like commutativity. I don't > think the language should pre-specify whether < is a partial or total > ordering. Any choice of this kind the language makes will inevitably turn > out wrong a significant percentage of the time. For proper orthogonality we > should not specify as much as we can about each operator, but as *little* as > we can and still have readable code. > > I would say the contract for < is just "takes operands of the same > unspecified type; returns a bool". The fact that this will usually be used > to express an order for sorting, and that it is anticommutative, is none of > the compiler's business. It's a convention that libraries will observe and > programmers know about, but that's a different matter. >
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?) (Also, does this mean the compiler wouldn't be able to make any optimization assumptions regarding whether an operation is commutative/associative/distributive?) - Dave -- 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.
