Operator/concept interoperability

[Mason McGill via Digitalmars-d]

On Tuesday, 3 June 2014 at 22:05:29 UTC, TheFlyingFiddle wrote:
> Well one reason for this is that unlike methods it is hard to
> resolve ambiguity between diffrent operator overloads that have
> been defined in diffrent modules.
>
> Example: 2D-vectors
> //vector.d
> struct Vector
> {
>     float x, y;
> }
>
> //cartesian.d
> Vector opBinary(string op : "+")(ref Vector lhs, ref Vector rhs)
> {
>    //Code for adding two cartesian vectors.
> }
>
> //polar.d
> Vector opBinary(string op : "+")(ref Vector lhs, ref Vector rhs)
> {
>     //Code for adding two polar vectors.
> }
>
> //main.d
> import polar, vector;
> void main()
> {
>     auto a = Vector(2, 5);
>     auto b = Vector(4, 10);
>
>     auto c = a + b; //What overload should we pick here?
>
>     //This ambiguity could potentially be resolved like this:
>     auto d = polar.opBinary!"+"(a, b);
>     //But... This defeats the whole purpose of operators.
> }

Interesting point. However, I believe this is also the case for 
ordinary functions used with UFCS:

   // cartesian.d
   Vector add(ref Vector lhs, ref Vector rhs)
     { /* Code for adding two cartesian vectors. */ }

   // polar.d
   Vector add(ref Vector lhs, ref Vector rhs)
     { /* Code for adding two polar vectors. */ }

   // main.d
   import polar, vector;
   void main()
   {
       auto a = Vector(2, 5);
       auto b = Vector(4, 10);
       auto c = a.add(b); // What overload should we pick here?

       // The fully qualified form looks quite different,
       // but it's rare, and intentionally explicit about what's
       // really going on, so that's OK.
       auto d = polar.add(a, b);
   }

It strikes me that ambiguous cases are not nearly as common as 
unambiguous cases, especially if you use selective imports.

I believe Julia uses a re-write rule for its operators: the first 
thing the compiler does when evaluating an operator expression is 
re-write it as a function call; after that, all the language's 
resolution rules apply as they would to any other function call. 
D could easily take this approach, simplifying the language while 
maintaining backwards-compatibility.

> Side note:
>
> You can achieve what you want to do with template mixins.
>
> ...
>
> While this implementation is not as clean as global operator
> overloading it works today and it makes it very simple to add
> operators to new types of grids.

Thanks for the example. This is actually my current solution :) 
However, as you allude to, I'm not a huge fan of it because

1) It requires boilerplate on the part of library users.
2) It makes you scratch your head and go "Huh; operator and 
non-operator functions have different compile-time polymorphism 
capabilities; why is that?"