How will we fix opEquals?

[Jonathan M Davis]

On Thursday 10 February 2011 12:22:48 Don wrote:
> Steven Schveighoffer wrote:
> > On Thu, 10 Feb 2011 10:19:50 -0500, Andrei Alexandrescu
> > 
> > <SeeWebsiteForEmail at 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.

I'd argue that silently changing function signatures is a _bad_ idea. And when 
they actually try and do something which would violate the constness of the 
function, they're going to be left scratching their head as to why a non-const 
function is getting complaints about const. In general, D has opted to _not_ do 
things silently. C++ did a fair bit of it in certain places (albeit not with 
const), and it's caused problems. I don't think that this would be as big a 
problem, but I still don't think that it's a good idea.

Really, while it's reasonable to not force D programmers to use const all over 
the place, I do _not_ think that it's reasonable for a D programmer to not be 
aware of const. And since opEquals, opCmp, toHash, and toString/writeTo all need 
to be const, the programmer is just going to have to deal with that fact. And 
having to put const on a few functions is likely to cause less pain than figuring 
out why they're getting errors with regards to const when they never use const 
anywhere.

- Jonathan M Davis