On Thursday, October 05, 2017 13:36:23 Timon Gehr via Digitalmars-d wrote:
> > On 27 September 2017 at 17:41, Ilya Yaroshenko via Digitalmars-d
> > <digitalmars-d@puremagic.com> wrote: I would prefer outer operator
> > overloading be added to D instead of type wrappers. So a user can
> > import a library for operations, rather then library of wrappers.
> > --Ilya
> "outer operator overloading" is UFCS for operators. I.e.:
>
> struct S{ int x; }
> S opBinary(string op:"+")(S a,S b){ return S(a.x+b.x); }
>
> void main(){
> auto s=S(3), t=S(4);
> import std.stdio;
> writeln(s+t); // S(7)
> }
>
> Starting from:
>
> s+t
>
> It rewritten to (as per the spec):
> s.opBinary!"+"(t)
>
> and then UFCS is applied (as per the spec):
> opBinary!"+"(s,t)
>
>
> I'm very much in favor of this. Also, those rewrites should be
> consistently applied for all types, even built-ins (the compiler
> implementation can be more complex, but the language rules would be
> simplified).
> One immediate benefit would be that opCmp could be reliably used for all
> types that support comparison, for example 2.opCmp(3).
> Another benefit would be that operators such as += can reassign class
> references, for example when a value type is implemented as a unique
> reference to immutable data.
Being able to do 2.opCmp(3) would be pretty cool, but I'm still convinced
that allowing for operators to be overloaded outside of the type is a
terrible idea. It's far cleaner for them to be tied to the type - especially
when you consider that it's not possible to differentiate between
conflicting overloadeded operators. And having them declared outside of the
type just opens up all of the problems that were just being complained about
in this thread with templated code not being able to access free functions
that weren't imported in the module that it's in.
- Jonathan M Davis
