Steven Schveighoffer wrote:
On Thu, 10 Feb 2011 10:19:50 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 2/10/11 2:58 AM, Peter Alexander wrote:
On 10/02/11 8:19 AM, Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEquals() is in conflict with this, since it is a member function of
Object.
(1) If it is a const member function, then it will have a viral effect
on all objects -- any function called by opEquals will have to be
marked
const.
(2) If it is not const, then const objects cannot be compared!
Currently, it's not const, but the problem isn't visible because of
compiler bug 5080. (Same problem applies to opCmp).
How will we break this dilemma?
It's not possible.
It is, in fact, possible. We can define two opEquals overloads, for
const and non-const. By default, the non-const version forwards to the
const one.
This doesn't work. If you only define one, then you will have problems
with hidden function errors, and/or inconsistencies. For example, how
does .opEquals(Object obj1, Object obj2) know which version to call?
I think the only true solution is to make it const and call it a day.
-Steve
I fear that you're probably right. The const opEquals must exist,
otherwise the object will be unable to use most functions in Phobos.
And I don't see how it can safely be synthesised from non-const opEquals.
A tiny compromise which could be made, is to silently add 'const' to any
class opEquals declaration, even if not present in the source. That way,
simple use cases would still compile without complaint.
(As long as only a single, precisely defined opEquals signature is
permitted, I think any other signature should be flagged as an error --
but it could be converted to the correct signature, instead).
Dunno if this would be worth it, though.
