On Thu, Oct 18, 2018 at 12:28 PM Ian Denhardt <i...@zenhack.net> wrote:
>
> Quoting Andy Balholm (2018-10-18 14:00:52)
>
> > That would also be a weakness of most of the other proposals,
> > including my own to add operators to interfaces. Contracts are more
> > powerful, at the expense of extra complexity.
>
> Fwiw, my own proposal for "just using interfaces" covered the graph use
> case. The code doesn't look far off from what Burak sketched in a
> sibling comment, but does have some key differences that I think are
> important to bridge the gap:
>
>     
> https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d#mutually-referential-type-parameters
>
> I think adding operators to that proposal actually covers every use case
> covered by the draft design. I left them out originally because of a
> snafu with the == operator, but ESR has offered a way around that.
>
> ---
>
> I feel like Burak's proposal is falling into the same trap as many others:
> there is a common feeling that operator overloading is a Pandora's box, so
> folks are trying to work around it by solving the problem without providing
> operator overloading. But *the problem itself* is not being able to abstract
> over operators, so this approach is doomed to failure. You just result in a
> clumsy design that can't decide if it's trying to allow operators to be
> abstracted over or not, since the whole point is to allow this, but the
> particulars of the design are motivated by a fear of actually doing so.


tbh, I am not trying to avoid operator overloading, I am trying to
avoid the contracts. With operator overloading, you can write:

func F(a,b type T like(int,X)) {
   if a<b {
     ...
   }
}

provided X is a type that supports <.


>
> I there is a fundamental conflict here. You can express the same concepts
> as with operator overloading if you're willing to wrap the basic types and use
> methods like .Less() in generic code. 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.
>
> -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.

Reply via email to