Well, whatever you may think of it, there's no doubt that a lot of the
problems we currently have with generic constraints would go away if
operator overloading were introduced into Go 2.
Personally, I wouldn't be dismayed if this were to happen. A lot of my
stuff is mathematical in nature and this is an area where operator
overloading works best - and indeed is expected - by programmers working in
these disciplines.
However, I think it's important to learn the lessons of the past and not
follow languages such as C++ or Scala where you can overload virtually
anything or even make up your own operators which can result in confusing
or even write-only code.
It is far better, in my view, just to permit the overloading of a limited
subset of operators and for their signature, priority etc. to mirror those
of the built-in ones.
In particular, I agree with Ian that there would be very little value in
overloading the logical operators (&&, || and !) and that this should be
disallowed.
I would also disallow overloading of the =, :=, <-, ..., [], {}, () and yes
- equality operators - as well because I believe to do otherwise would be
very confusing.
The equality operators (== and !=) have a well defined meaning in Go 1
which spans both built-in and user defined types and, to maintain backwards
compatibility, I don't think this should be changed. When you want to use
these operators purely for ordering purposes, they can always be reproduced
by a combination of the other ordering operators as I said in another
recent thread.
If you can't overload == and != then 'comparable' (or whatever you want to
call it) would need to be a built-in interface.
Another possibility would be to introduce two new ordering operators,
perhaps >< (for ==) and <> (for !=), which *could* be overloaded though the
first of these would take some getting used to!
As for Eric's proposal - using an 'implements' keyword - I like it for the
following reasons:
1. It avoids the need to make up a long list of names for the operators
which folks either have to remember or look up in the spec.
2. It makes it easier to retrofit operator overloading to existing types
for which suitable methods have already been defined.
3. As 'implements' would only be used in contexts which don't exist at
present, it needn't be a 'full' keyword and would therefore be backwards
compatible.
One area that hasn't been addressed so far is conversions. To convert to
say, int64, I'd suggest 'implements int64()' and to convert from int64
perhaps 'implements T(int64)' where T is the method's receiver type. TBH, I
don't particularly like the idea of user-defined conversions at all but
they're probably inevitable if you want to have unified generic constraints
and at least they'd always be explicit.
Subject to all this, I think it might well be possible to get rid of
contracts and just use interfaces for generic constraints.
Incidentally, I'm not a fan of wrapping types so that they can support the
built-in operators. Although this is easy enough for scalar types, when you
have slices, maps etc. of such types it's a different kettle of fish as
wrapping/unwrapping requires a lot more code.
Alan
On Tuesday, October 16, 2018 at 3:24:50 AM UTC+1, Eric Raymond wrote:
>
> Recent discussion of possible generics designs has forced me to a
> conclusion I'm not happy with, because it requires a feature-cluster that I
> thought I was glad to be leaving behind in Python. That is this:
>
> The simplest and most effective way to solve the generics problem is to
> embrace operator overloading and the kind of magic method designations that
> go with it.
>
> I'm still not a big fan of operator overloading as a surface feature of
> the language. I think the arguments that it encourages overly clever
> one-liners are sound. My argument is not in favor of that. Rather, after
> reviewing all the design strawmen I have seen, I see no way to declare
> contracts for generics that is (a) as simple, and (this is a really
> important point brought out in a recent post) maintains unification with
> primitive types.
>
> In fact, more and more as I look at the proposals that have failed to
> catch fire I see them as clever but doomed attempts to evade operator
> overloading because most people did not want that camel's nose in the
> tent. As a matter of cold fact I don't either, but I am forced to the
> conclusion that in the portion of design space we can easily reach from Go
> 1, operator overloading and contracts are more joined at the hip than
> anyone - including me - has been willing to face up to now. I therefore
> propose that we embrace the suck and limit the complexity load on the rest
> of the language as much as possible.
>
> Here's a stupid-simple system for describing generic contracts with just
> one new keyword: "implements", having a single argument which is a token
> that may occur as an operator in expressions. Here is what it would look
> like:
>
> type Sortable interface {
> implements <
> }
>
> type MySortable struct {
> name string
> sortkey id
> }
>
> func (r MySortable) LessThan (s MySortable) bool implements < {
> return r.sortkey < s.sortkey
> }
>
> Because MySortable has a method that "imnplements <", it satisfies the
> Sortable interface.
>
> Each eligible operator has an implied generic signature. For example is
> we use s and t as generic argument placeholders, that of < is
> s.(T).func(t T) bool. That of + would be s.(T).func(t T) T. It would be
> a compile-time error for an "implements" method not to match the signature
> template of its operator as it applies to basic types.
>
> The general insight this leverages is that every primitive-type operator
> implies a description of a contract *without adding any additional
> complexity to the language*.
>
> Notice that we have evaded the methods themselves needing to have magic
> names. The only declaration of contract and overloading is the
> "implements" clause.
>
> This passes Ian's smoke test. That is, it is easy to see how to implement
> min() and max() on generics under this system.
>
> By being able to define relationals and + or * as a composition operator
> for algebras on user-defined types I think we solve a huge part of the
> generic contracts problem. At the cost of adding only one new construct to
> the language, and one that is easy to describe and understand. (Because
> the heavy lifting is done by well-established expectations about the
> behavior of primitive types.)
>
> Perhaps I risk overreaching, for I am relatively new to the language, but
> it seems to me that the simplicity and orthogonality of this proposal are
> very much in the spirit of Go. Enough to that the side effect of
> overloading as a surface syntactic feature is - if grudgingly - forgivable.
>
> Can it even possibly be simpler than this? What, if anything, am I missing?
>
>
>
>
>
>
--
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.
