On 10/5/17 6:04 PM, Jonathan M Davis wrote:
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
<[email protected]> 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.

But UFCS already has all these "problems", and yet it's one of the most useful features of D.

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.

That is a problem, but no different from any other UFCS scheme.

Indeed, providing a way to alias "official" UFCS functions into the namespace of the type itself would be useful.

-Steve

Reply via email to