On Sunday, 17 July 2016 at 12:38:46 UTC, Andrei Alexandrescu
wrote:
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
It's certainly true that if I see "mutable" used in code, it
catches my attention and engages my extreme skepticism. It is
very hard to get right. Yet, in the handful of cases I've ever
seen it used, the people who used it generally knew what they
were doing and did get it right. And banning mutable in those
situations would have caused a cascade of non-const reaching far
up into the system, where it wasn't wanted and would remove
important protections.
I read N2669 and it doesn't "effectively prohibit" mutable as far
as I can see. It does mean that to use any mutable state you'd
need protection, such as locks, or lockfree trickery.
Generally, I suspect that the only allowable
externally-observable effect of using "mutable" is improved
performance. But perhaps there is some other valid use that I
just haven't encountered.
