Getting the const-correctness of Object sorted once and for all

[H. S. Teoh]

On Mon, May 14, 2012 at 09:18:42PM +0200, deadalnix wrote:
[...]
> Lazy initialization is more a problem than a solution when it comes
> to multithreading. And I'm afraid it is the future.
> 
> BTW, nothing prevent to define toString an non const and another as
> const. The const one cannot cache the result, but certainly can read
> it. And every method that is aware of the non const version will use
> it.
> 
> This whole thing is overinflated. This isn't a problem. I'm pretty
> sure that most code that will broke was actually already a bad idea
> in the first place.

I agree. Existing stuff that use toString makes certain assumptions
about it, const being one of them. Things like toHash() falls back to
hashing the value of toString() if no other suitable default is found.
It would be a very very bad idea if accessing AA's start causing network
access, for example.

If you really, really, REALLY absolutely have to have non-const
toString, then just define one. Then code that is aware of the non-const
version will use it, and that code will actually be aware of the
consequences. It's a bad idea to do things like network access in the
const version of toString() when existing code that uses it (built-in
stuff like druntime) assumes this doesn't happen.


T

-- 
A linguistics professor was lecturing to his class one day. "In
English," he said, "A double negative forms a positive. In some
languages, though, such as Russian, a double negative is still a
negative. However, there is no language wherein a double positive can
form a negative." A voice from the back of the room piped up, "Yeah,
yeah."