On Fri, Oct 19, 2018 at 11:48 AM Eric S. Raymond <e...@thyrsus.com> wrote:
>
> 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
I agree that "implements" construct solves a lot of problems.
However:
Without operator overloading:
type X interface {
implements <
}
means that you want a primitive numeric type or a string. So:
type Y like(int,string)
Even though it is not as precise as the interface with implements, it
means the same thing.
Assuming you have operator overloading, the X interface will
accept any primitive or struct type that implements <, whereas Y
won't. However, when you have operator overloading, you can still use:
type Y like(X)
So the question is: do we really need to declare exactly what the
implementation of a generic needs in the contract, or is it sufficient
to say "use this with values that are like type X"?
Another thing that motivated me to start this thread in the first
place was imagining myself sitting late at night trying to figure out
how to convert a huge chunk of code to a generic type, and reading
through to figure out exactly what the contract is. With the "like"
syntax, I could simply add "like X" to my arguments, and be done with
it. With interfaces containing "implements", I have to write those
interfaces and figure out exactly what I need. With contracts, I
imagine someone would come up with a tool to build that from the
source if it comes to that.
.
>
> * 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.
