Vision for the D language - stabilizing complexity?

[Andrew Godfrey via Digitalmars-d]

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.