Vision for the D language - stabilizing complexity?

[Andrei Alexandrescu via Digitalmars-d]

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