Operator overloading through UFCS doesn't work

[Timon Gehr]

On 10/14/2012 12:36 AM, H. S. Teoh wrote:
> On Sun, Oct 14, 2012 at 12:12:01AM +0200, Timon Gehr wrote:
>> On 10/13/2012 10:15 PM, Jonathan M Davis wrote:
> [...]
>>> but they _aren't_ mixed and they will _never_ be mixed. If it had
>>> _ever_ been intended that it be possible to overload operators as
>>> free functions, then we'd simply have made it so that you could
>>> declare a free function like
>>>
>>> auto opBinary(string op)(Foo foo, Bar bar)
>>> {
>>>     ...
>>> }
>>>
>>> in the first place  without requiring that it be a member function.
>>
>> You can.
>>
>>> But it _was_ required to be a member function, and it would make no
>>> sense to allow a new feature to circumvent that restriction. If it
>>> was supposed to be circumventable, then the restriction wouldn't have
>>> been put there in the first place.
>>
>> This argument is even less convincing in the context of an informally
>> specified language with a somewhat buggy reference compiler.
>
> OK, before this thread devolves into a shouting match, I'd like to
> understand what was the rationale behind this restriction. What were the
> reasons behind not allowing a non-member function to overload an
> operator? What are the pros and cons considered at the time, and how do
> they weigh now? Or was it just a matter of not being implemented because
> nobody thought about it at the time?
>
>
> T
>

Afaik free-function operator overloads (but not in the context of
UFCS) were considered and turned down because D did not want to get
amidst discussions about adding Koenig lookup. UFCS does not do Koenig
lookup.