Should we add `a * b` for vectors?

[Timon Gehr]

On 06.10.2017 03:01, Walter Bright wrote:
> On 10/5/2017 4:26 AM, Timon Gehr wrote:
>>> I know that some of the UFCS code was written without regard to 
>>> hijacking.
>>> ...
>>
>> I think it is by design. Lookup first tries to find members of the 
>> type, and only if they don't exist applies UFCS lookup. Therefore, if 
>> members are added to the type or made visible, this may hijack 
>> existing UFCS usages.
> 
> It may have been done that way to avoid breaking existing code.
> 

I think so. It can break new code though. ;)

>> The way to fix it is to do UFCS lookup always and then error out if 
>> both UFCS and member lookup match, but there is probably quite some 
>> code relying on the fact that you can provide a custom implementation 
>> of a general UFCS function by just adding a member. Also, with the 
>> hijacking error if you actually meant the member function the only way 
>> out I see is to use __traits(getMember, ...) for disambiguation.
>>
>> (BTW: Local imports allow hijacking too. Maybe this one could be fixed?)
> 
> I thought that was taken care of when the whole import lookup mechanism 
> was redone a year or two ago.
> ...

https://issues.dlang.org/show_bug.cgi?id=17589

I think the best fix is what I quickly outline at the end of the issue. 
It is originally a proposal of deadalnix:
https://issues.dlang.org/show_bug.cgi?id=10378#c9

> ...
> 
>>> D's name lookup rules were quite simple, and deliberately set up that 
>>> way. Unfortunately, most people thought they were unintuitive. It 
>>> turns out that simple algorithms are not intuitive, and we now have a 
>>> fairly complex lookup system. Martin and I implemented it, and 
>>> probably neither of us completely understands it. I find it 
>>> regrettable that things have gotten to that state.
>>> ...
>>
>> It might make sense to sit down at some point and see what goals the 
>> complex rules try to achieve and then come up with simpler rules that 
>> achieve the same (or better) goals.
> 
> There wasn't a lack of discussion about the import lookup rules :-)
> ...

The only related issue of which I was aware was visibility of private 
symbols. (I.e. private symbols should not cause conflicts with public 
symbols in other modules.)

> ... >>> Doing this kind of wrapper doesn't work for operator overloading,
>>> which brings us back to ADL is for operator overloading.
>>
>> Why does it not work for operator overloading?
> 
> 3+s

typeof(s) could overload opBinaryRight, no?