On 7/15/16 10:43 AM, Andrew Godfrey wrote:
On Friday, 15 July 2016 at 11:09:24 UTC, Patrick Schluter wrote:
On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh wrote:
I think the one that hurts the most is fixing "C++ fault" #3. It
means there are many scenarios in which I could put const in C++, and
I simply can't in D, because something somewhere needs to be mutable.
Then it is not const and marking it as const is a bug. D enforces to
not write a bug, what's wrong with that?
One example is if you make a class that has an internal cache of
something. Updating or invalidating that cache has no logical effect on
the externally-observable state of the class. So you should be able to
modify the cache even on a 'const' object. This is not a bug and I've
seen it have a huge effect on performance - probably a lot more than the
const optimizations Walter is talking about here.
I suggest you take a look at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2669.htm. It
adds guarantees for STL containers that effectively prohibit them from
using mutable. If they do use mutable, they are on their own in ensuring
correctness. Also, although arguably all types should behave that way,
there is no way to express something near "this user-defined type
satisfies N2669" within the C++ type system. Also, N2669 encodes
existing practice; the whole logical const and surreptitious caches
inside apparently const objects is liable to bring more problems than it
solves (see e.g. the std::string reference counting fiasco). -- Andrei
