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.
