Should we add `a * b` for vectors?

[Steven Schveighoffer]

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
>>> <digitalmars-d at 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.

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