Burak Serdar <bser...@ieee.org>:
> Where can I read about this "implements"? Link?

https://groups.google.com/forum/#!topic/golang-nuts/pR5pmql5olM

After subsequent discussion I would only add these points:

* The "implements" construct is not a full generic-type system in
itself, nor is it meant to be.  It's meant to be an orthogonal piece
that replaces heavyweight contracts proposals, and needs to be mated
with a system ot parametric polymorphism and one of type composition.

* To the compiler, the contract implied by each operator is just its type
signature (e.g '<' has the signature a.(T).func(b T) bool) and
precedence.  The semantics of what each possible operator means
(e.g. < is for sorting, + is a concatenation operator) is a social
convention expressed by how the operator is used by the standard
library and packages.

* Other considerations in the language imply a rule that operators on pointer
types cannot have implements methods (but non-pointer types can have implements
methods with pointer receivers).

* There is room for debate about which operators can be the subject of
an implements clause. Everybody clearly wants < + - == | & (what you
need to do set algebra) and I think ! is important. There is a
general feeling that =+ =- and friends should not be overloadable but
should be considered lexical abbreviations in the obvious way.

* There is debate about whether there should be implied overloading - that is
if a method foo(a T, b T) implements == should it be the case that not
only a == b translates to foo(a, b) but a != b translates to !foo(a, b).

I'm not strongly attached to a position on either of the debates. I
note howvever that I do not want a < b to imply !(b > a) because I do
things with graphs and lattice algebra and want to be able to express
partial (not just total) ordering.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-- 
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.

Reply via email to