> Ian Denhardt <i...@zenhack.net>:
> > But I think fundamentally folks have to
> > make choice: do we want to be able to write `<` for user defined types, or
> > do
> > we want to be able to look at the `<` operator and know for certain that
> > it's
> > not calling a method? You can't have both.
You can have almost both by using one of these syntaxes in
parametrically typed functions:
a (<) b
or
a <() b
This syntax would only be necessary in parametrically typed functions
and probably should be prohibited in non-parametrically typed functions.
You end up with explicitly-marked overloaded operators.
* Eric S. Raymond <e...@thyrsus.com> [181019 12:38]:
> This is why I confidently predict that nobody will find a simpler way
> to approximate contracts than "implements". Ever.
My declarative contracts are almost as simple, but require
parametrically typed functions, and are much more flexible and
expressive.
I do like your idea, but I don't think it is the correct approach to
adding generic programming features to Go.
> Of course "implements" is not an entire generic system; we need syntax
> and semantics for parametric polymorphism and parametric types, too.
> But it's a *good thing* that "implements" can be described without any
> reference to these concerns; it means we have *orthogonality*.
No, you have conflated two ideas that have corresponding features, but
are orthogonal to each other (interfaces and operator overloading). If
you don't also implement parametrically typed functions, you have lost
much of the flexibility that has been requested with generics. If you
do, than operator overloading belongs with contracts not with
interfaces.
The general paradigm of interfaces is that they represent boxed values.
Interface values are represented in memory as boxed values, and the code
generated by the compiler handles them as boxed values.
If generic programming in Go uses boxed values, we have gained very
little over interfaces. This means we should not use interfaces as the
language basis for generic programming. If we do, we either end up with
generic programming with boxed values or we end up with interfaces that
sometimes use boxed values and sometimes do not, depending on what is
in the interface.
For generic programming, the Go compiler should produce specialized code
for each type combination that is used, except where more than one type
produces the same machine code.
I personally believe that parametrically typed functions without
operator overloading will satisfy about 80% of the use cases and is much
more important than operator overloading. However, I realize that there
is a large segment of Go programmers that would like to use familiar
operators with user-defined types. I like the explicitly marked
overloaded operators for reasons of cognitive load when maintaining
code, and I hope that they will satisfy this segment of the programmer
population.
...Marvin
--
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.
