[Issue 3659] Too much exegesis on opEquals

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3659


Steven Schveighoffer <schveiguy at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy at yahoo.com


--- Comment #2 from Steven Schveighoffer <schveiguy at yahoo.com> 2009-12-31 05:51:24 PST ---
Here is the issue.  The compiler now is required to generate an opEquals which
calls x.m == y.m on all members m of the struct (this was to fix bug 3433). 
However, in order for this opEquals to handle const and immutable versions of
the struct, the opEquals generated needs to be const.  Given that, if member m
is another struct with a *user defined* opEquals, that opEquals must *also* be
const.

The current rule is too strict, I agree.  For instance, you should not require
that the argument be ref const if the argument type can be implicitly cast from
const to mutable (i.e. a pure value type), but if the argument is ref, it
*should* be const, and the opEquals function itself *should* be const. 
Otherwise, you could be changing stuff just by doing a comparison.

What is the use case for an opEquals not being const?

Another alternative is to allow any signature for opEquals on type T, but then
any type U which has a member of type T will be illegal to compare unless type
U also defines opEquals.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------