Operator overloading through UFCS doesn't work

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Oct 13 15:36:19 PDT 2012


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

-- 
Why can't you just be a nonconformist like everyone else? -- YHL


More information about the Digitalmars-d-learn mailing list