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.
