Dicebot on leaving D: It is anarchy driven development in all its glory.

[Timon Gehr]

On 28.08.2018 19:02, H. S. Teoh wrote:
> On Tue, Aug 28, 2018 at 08:18:57AM +0000, Eugene Wissner via Digitalmars-d wrote:
> [...]
>> There are still valid use cases where const should be "broken". One of
>> them is mutex (another one caching). I have very little experiance in
>> multi-threaded programming, but what do you think about "mutable"
>> members, despite the object is const?
> The problem with compromising const is that it would invalidate any
> guarantees const may have provided.

No. You start with the set of allowed program rewrites, then require 
code with __mutable to not break under them. Code using __mutable is unsafe.

> Const in D is not the same as const
> in languages like C++; const in D means*physical*  const, as in, the
> data might reside in ROM where it's physically impossible to modify.
> Allowing the user to bypass this means UB if the data exists in ROM.
> 
> Plus, the whole point of const in D is that it is machine-verifiable,
> i.e., the compiler checks that the code does not break const in any way
> and therefore you are guaranteed (barring compiler bugs) that the data
> does not change.  If const were not machine-verifiable, it would be
> nothing more than programming by convention, since it would guarantee
> nothing.  Allowing const to be "broken" somewhere would mean it's no
> longer machine-verifiable (you need a human to verify whether the
> semantics are still correct).

It is not unusual to need a human to verify that your code does what it 
was intended to do.