Vision for the D language - stabilizing complexity?

[deadalnix via Digitalmars-d]

On Friday, 15 July 2016 at 14:43:35 UTC, 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.

That's actually not true. Memory barrier needs to be emitted, and 
considered in the caller code.