(Sorry about the post fragment that got away from me.) On Tuesday, October 16, 2018 at 3:33:58 PM UTC-4, Ian Denhardt wrote: > > > The alternative though is having to implement several different methods > with obvious implementations in terms of one another, and make sure > they're consistent.
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. -- 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.
