On Sat, Sep 8, 2018 at 3:47 PM, Ignazio Di Napoli <neclep...@gmail.com> 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;
> }
As I've said before, I would very much like to avoid adding many
different names to the language. Also, there are many different cases
to handle. Consider type conversions, for example; how do you express
that you want to have two types, with one being convertible to the
other? I encourage you to work through the various examples in the
design draft and consider how to write them.
Ian
--
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.
