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.
