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