Behavior of opEquals

[H. S. Teoh via Digitalmars-d]

On Fri, Sep 04, 2015 at 07:10:25PM +0000, Jonathan M Davis via Digitalmars-d wrote:
> On Thursday, 3 September 2015 at 13:05:49 UTC, Steven Schveighoffer wrote:
> >On 9/2/15 2:57 PM, Jacob Carlborg wrote:
> >
> >>In this case the solution/workaround is to explicitly call
> >>super.opEquals, but that will miss some optimizations implemented in
> >>object.opEquals.
> >
> >Those optimizations have already been exploited by the time you get
> >to Foo.opEquals, so I wouldn't worry about that.
> >
> >However, the avoidance of casting would be a good goal. One of the
> >things I don't like about the current == implementation for objects
> >is it cannot take any advantage of type knowledge at the call site.
> 
> Every time I've tried to templatize the free function opEquals, [...]
[...]

Wait, wait, did I miss something? Since when was operator overloading
allowed as free functions? Or is opEquals a special case?


T

-- 
If it tastes good, it's probably bad for you.