Quoting alan.f...@gmail.com (2018-10-13 15:39:46) > Unfortunately, no approach is immune to silly mistakes by yours truly > but, as it's an area where "Effective Go" could offer some pointers, it > need not be unduly error prone in practice.
Still, some approaches are more error prone than others. It's hard to make a compelling argument without data, but it seems like directly defining Less() would be easier to get right than having to come up with some encoding that preserves your intended notion of equality. > The problem with associating operators with named methods is that there > will be a lot of names for people to remember (or to list in the spec) I think you could take an approach where you only have one method per "category" of operators. So for example, rather than having separate methods for each of <, >, <=, and >=, you could just have: x < y desugars to x.Less(y) x > y desugars to y.Less(x) x >= y desugars to !x.Less(y) x <= y desugars to !y.Less(x) Similarly, for == and != you could just define a method `Equal`, and have: x == y desugars to x.Equal(y) x != y desugars to !x.Equal(y) There are some deeper problems with overloading == with a method, namely that right now == does different things for Foo and *Foo, which is not something that is generally possible for methods, but your proposal has the same problem. > and, given that the built-ins don't have methods, it is unclear > what mechanism could be used to achieve this association. My first thought is that we could just change the language such that built-in types *do* have methods. -- 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.
