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.
Oh, and this is interesting, I implemented a B+tree-like data structure* in C# that supports O(1) cloning. It marks the root as "frozen", making it copy-on-write. In order to clone in O(1), the children are not marked as frozen until later, when someone actually wants to mutate one of the copies. A user can also make the tree immutable in O(1) time and freely make mutable copies of it. This use case is pretty complex, so if I port this to D, I'd probably just cast away const/immutable where necessary. C#, of course, has no const so it was never a concern there. *it's actually way fancier than that, I should really write a CodeProject article on it. Of course, the trouble is, you can call any const method on an immutable object, so any const method that mutates needs to be thread safe. Many uses of C++ 'mutable' are thread-safe (e.g. most platforms guarantee atomic pointer-size writes, right? So two threads can cache the same int or two equivalent class instances, and it doesn't matter who wins)... but many other cases are not (e.g. the hashtable). This is not a solved problem, is it. Ideas?
One idea we're considering is to plant a pointer to mutable data together with the mutex pointer in classes.
Andrei
