I don't think Go will add operator overloading, even if it simplifies
generics. Go has a core principle that doesn't get written down very much:
syntax is hard-coded. If you see a piece of syntax in Go, it will never
execute user code. (The obvious exception, of course, is a function call.)
This principle makes Go extremely readable, and relatively easy to debug.
Even if Go had operator overloading, there's more to do. You talk about
"slightly extended interfaces," but what are those? Your example
type comparer(type T) interface {
Less(other T)
}
interpreted according to the current design, only describes some type U
that has a method with signature Less(T). It doesn't say U and T are
identical. You need to be more clear about what changes to interfaces are
necessary.
Lastly, there's the problem of contracts with multiple type parameters,
like the Graph example in the design draft. Operator overloading doesn't
help with that.
On Saturday, September 8, 2018 at 6:47:30 PM UTC-4, Ignazio Di Napoli wrote:
>
> I'd really like to read a reply to Lucio's argument about operator
> overloading.
>
> Once we define that:
> 1. a<b is syntactic sugar for a.Less(b) (with a and b being of the same
> type);
> 2. a==b is the same as a.Equals(b);
> 3. the other comparaison operators are defined using these two (e.g.: a>b
> is !a.Less(b) && !a.Equals(b));
> 4. a.Index(b) is the same as a[b] and a.Index2(b, c) is the same as a[b:c];
> 5. maybe some more?
> Would we really need contracts and the added complexity in this case?
> Shouldn't slightly extended interfaces suffice?
>
> E.g.:
>
> type comparer(type T) interface {
> Less(other T)
> }
>
> func min(type T comparer)(a, b T) {
> if a < b {
> return a;
> }
> return b;
> }
>
>
--
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.
