What you've just suggested there has the makings of a decent proposal in itself :)
But I think it would inevitably mean that the built-in types would need to have methods or at least pseudo-methods for special purposes. Of course, it may that this is a problem which isn't really worth solving by introducing a language change and we should simply accept that the built-ins can't be married to other types and therefore we'll always need two sets of functions to deal with them both. In my own proposal on generic constraints, I started from this premise though, when I saw that some folks were attaching importance to a unified approach, I began wondering about whether there was a plausible way to achieve this - hence this proposal. Alan On Saturday, October 13, 2018 at 9:08:34 PM UTC+1, Ian Denhardt wrote: > > Quoting alan...@gmail.com <javascript:> (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.
