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