Vision for the D language - stabilizing complexity?

[Dicebot via Digitalmars-d]

On 07/15/2016 05:43 PM, 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.

Yes and the fact that D prohibits this incredibly common C++ design
anti-pattern makes me very grateful about such choice. Logical const is
terrible - either don't mark such objects as const or make cache separate.