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."
