On Mon, Jul 09, 2012 at 08:07:22PM +0200, Timon Gehr wrote: > On 07/09/2012 07:49 PM, Andrei Alexandrescu wrote: > >On 7/9/12 12:34 PM, David Piepgrass wrote: > >>I guess D does not have 'mutable' (like C++) to override const on > >>methods? > > > >It doesn't, which makes life difficult for certain idioms. On the > >upside, you can assume more than C++ does about immutable data. > > > >>Caching anything slow-to-compute is my typical use case, and I know > >>a hashtable design where the getter will move whatever value at > >>finds to the front of a hash collision chain. > > > >Yah, that won't be easy to implement. We have a couple of designs in > >mind for "mutable", but didn't get to it. Regarding advantages, think > >of this - if an immutable instance of your bring-to-front hashtable > >were used by multiple threads it would fail because it's "lying" > >about its being immutable. For now just don't use const for what > >ain't. > > > > This is very inconvenient if the root of the class hierarchy uses it. [...]
I'm wondering if it makes any sense to have _also_ have non-const versions of things like toString, for objects that want to implement caching. So in contexts where const is not important, you can have caching, network access, whatever you want, but for core language stuff that needs to assume const, everything will still work (just a little slower). I'm thinking of the case where some objects might be kept in ROM, say, in which case you can't cache within the class, even if you wanted to. But for other instances of the class that are outside ROM, you can be free to use the non-const, caching, network-accessing version of toString to your heart's content. After all, we have inout for a reason; here's a case where we need to do the opposite of inout (have both a const and non-const version of a method). Or am I just spouting nonsense again? ;-) T -- Help a man when he is in trouble and he will remember you when he is in trouble again.