According to the specs
  http://dlang.org/operatoroverloading.html#equals
`object.opEquals' denies to call the `opEquals'-function tailored for the class of two objects `a' an `b' if for those objects `a is b' holds.

Although this seems resonable and reduces boiler-plate it makes it impossible to implement a side-effect for those cases.

I do not believe, that there is good reason to disallow side-effects in those cases. Therefore a mechanism to enable such side-effects should be implemented.

-manfred

On Thursday, 7 May 2015 at 14:37:14 UTC, Manfred Nowak wrote:
> According to the specs
>   http://dlang.org/operatoroverloading.html#equals
> `object.opEquals' denies to call the `opEquals'-function tailored for the class of two objects `a' an `b' if for those objects `a is b' holds.
>
> Although this seems resonable and reduces boiler-plate it makes it impossible to implement a side-effect for those cases.
>
> I do not believe, that there is good reason to disallow side-effects in those cases. Therefore a mechanism to enable such side-effects should be implemented.

And why not just use another function instead of opEquals for what you want?

- Jonathan M Davis

On Thursday, 7 May 2015 at 14:37:14 UTC, Manfred Nowak wrote:
> According to the specs
>   http://dlang.org/operatoroverloading.html#equals
> `object.opEquals' denies to call the `opEquals'-function tailored for the class of two objects `a' an `b' if for those objects `a is b' holds.
>
> Although this seems resonable and reduces boiler-plate it makes it impossible to implement a side-effect for those cases.
>
> I do not believe, that there is good reason to disallow side-effects in those cases. Therefore a mechanism to enable such side-effects should be implemented.
>
> -manfred

Having the base Object method check for 'is' itself results in not having to make a virtual call in, I would guess, about 40-50% of cases or even more. It's a performance benefit.

Jonathan M Davis wrote:

> And why not just use another function instead of opEquals for what you want?

Because the local `opEquals' _is_ the overload-function for `==' and `!='.

I guess that your "another function"-opinion holds for every form of overloading.

-manfred

Kapps wrote:
> It's a performance benefit.

There is no proof that every replacing mechanism necessarily degrades performance. Please recall, that for implmenting a side effect on all checked pairs of elements of a class, a virtual call is necassary anyway.

-manfred

On 5/8/15 10:11 AM, Manfred Nowak wrote:
> Kapps wrote:
>> It's a performance benefit.
>
> There is no proof that every replacing mechanism necessarily degrades
> performance. Please recall, that for implmenting a side effect on all
> checked pairs of elements of a class, a virtual call is necassary anyway.

The right answer to this is: opEquals is currently not replaceable and there are no plans to make it so. D is so flexible, people in this forum tend to take it for granted that any theoretical flexibility ought to be realized. There is, however, value in drawing boundaries, too.

Manfred, you will need to find other means to achieve what you need to do.


Andrei

On Friday, 8 May 2015 at 17:00:00 UTC, Manfred Nowak wrote:
> Jonathan M Davis wrote:
>
>> And why not just use another function instead of opEquals for what you want?
>
> Because the local `opEquals' _is_ the overload-function for `==' and `!='.
>
> I guess that your "another function"-opinion holds for every form of overloading.

In general, D is far more restrictive in how it defines overloaded operators than C++ is. This helps enforce the correctness and consistency of such operators and reduces how much code has to be written. Occasionally, that means that there are things that you can do in C++ with overloaded operators that you cannot do in D with overloaded operators, and perhaps that is a loss, but on the whole, it's well worth the gains (e.g. by defining only opEquals and opCmp, you get the whole suite of overloaded operators, whereas in C++, you'd have to implement each and every one of them individually, which is both far more verbose and far more error-prone).

So, if an overloaded operator does not work with what you're trying to do, then you need to use a function of your own to implement it.

- Jonathan M Davis

Andrei Alexandrescu wrote:
> you will need to find other means

If this is meant to be ex cathedra, then I am quiet.

-manfred

On Fri, 08 May 2015 16:59:59 +0000, Manfred Nowak wrote:

> Jonathan M Davis wrote:
> 
>> And why not just use another function instead of opEquals for what you want?
> 
> Because the local `opEquals' _is_ the overload-function for `==' and `!='.
> 
> I guess that your "another function"-opinion holds for every form of overloading.
> 
> -manfred

i'd be VERY surprised if `==` or `!=` does any mutation. and i (like most programmers) don't like such surprises in code.

ketmar wrote:
> i'd be VERY surprised if `==` or `!=` does any mutation. and i (like most programmers) don't like such surprises in code.

The side effect I used was logging. And me _was_ surprised not to get the expected number of log-lines.

-manfred