Inherited const when you need to mutate

[Jonathan M Davis]

On Tuesday, July 10, 2012 14:19:46 H. S. Teoh wrote:
> On Tue, Jul 10, 2012 at 04:11:05PM -0400, Jonathan M Davis wrote:
> > On Tuesday, July 10, 2012 12:00:59 H. S. Teoh wrote:
> > > I think hidden somewhere in this is an unconscious conflation of
> > > physical const with logical const.
> > 
> > I completely disagree at least as far as classes go. opEquals, opCmp,
> > toString, and toHash must be _physically_ const, because they must
> > work with physically const objects.

> Isn't there something we can do to improve this situation?

There may be. It's an open question. For opEquals, it was suggested (by Steven 
IIRC) that we could make it so that the free function opEquals works with both 
const and non-const objects such that if your class defines a non-const 
opEquals, and you compare mutable instances of that class, it would use the 
non-const version. It already has to be templated anyway. And if we make it so 
that Object has both a const and non-const overload of opEquals, then the 
appropriate one will be used. Classes which can be const have their non-const 
opEquals call their const opEquals, and those that can't throw an Error from 
the const version if it's ever called. We could probably do the same thing 
with the other 3 functions, and there have been other, similar proposals. 
Presumably, we can work _something_ out, but how best to do it is still an 
open question. However, regardless of whether we can sort out making classes 
which can't be const work, there's no question that we must have const 
versions of opEquals, opCmp, toString, and toHash on Object, otherwise const 
is horribly broken.

- Jonathan M Davis