Head Const

[Jonathan M Davis via Digitalmars-d]

On Thursday, 18 February 2016 at 22:40:32 UTC, Walter Bright 
wrote:
> On 2/18/2016 4:16 AM, Jonathan M Davis wrote:
>> headconst may solve the extern(C++) problem, but it really 
>> doesn't solve the
>> problems we have with const.
>
> 'mutable' doesn't really solve a problem, it just means that 
> C++ 'const' is a documentation aid, not a guarantee.

It's still a guarantee for those members that aren't mutable. 
It's allowing casting away const and mutating that totally blows 
the guarantees out of the water. You can actually look at the 
type to see which members are mutable and know what might change, 
and usually it's stuff like mutexes that are perfectly okay to 
change, whereas with casting, you'd have to look at every spec of 
code that uses the object to see what it does if you want to be 
sure that a const object or particular member isn't mutated.

And while I very much like the fact that D doesn't consider 
casting away const and mutating to be defined behavior and that 
it has stronger guarantees than C++, the reality of the matter is 
that in many cases, it ultimately provides far worse guarantees 
than C++. While C++'s const does have too many backdoors, at 
least when you use it, it catches accidental mutation (e.g. 
getting the arguments reversed when calling copy from the 
algorithm header will result in an error). But if you're forced 
to drop const entirely as tends to happen in D, then you don't 
get that. So, for some code, the stricter const in D is great, 
but for a lot of it, it makes things worse. In spite of the 
stronger guarantees, you ultimately end up with less protection. 
And since the compiler actually lets you cast away const and 
mutate in D to your heart's content without complaining at all 
(even if it's technically undefined behavior), there are plenty 
of folks that do it, because D doesn't provide mutable, and they 
assume that because you can cast away const, mutating it must be 
fine, just like with C++. So, while in principle, D's const 
provides better guarantees, in practice, it really doesn't. 
Casting away const would have to be illegal for it really provide 
those guarantees. And because it's so restrictive, it frequently 
gets avoided anyway. So, even if it doesn't get circumvented, it 
still fails to provide good guarantees, because it's not used.

At least if we added @mutable, we'd be providing a controlled 
means of escaping const in the cases where it's needed, avoiding 
issues with immutable like you'd potentially get if you cast away 
const and mutated. And any code which didn't use @mutable would 
be able to rely on the full guarantees that we have now (the only 
problem being folks that cast away const and mutated, thinking 
that it was okay, but they'd have less incentive to if they had 
@mutable).

In principle, I agree that having something like @mutable does 
weaken const, but in practice, it does a much better job of 
catching bugs, because then you're actually able to use const 
with more complicated objects. And unlike casting away const, 
@mutable is easily detected and accounted for.

D's const simply doesn't work once you start doing stuff like 
putting allocators or reference counts into the mix. And while 
maybe we could not care about that when we thought that it was 
fine to use the GC with everything, I think that we have a much 
harder time holding that position now. As principled as D's 
current position on const may be, it's highly impractical.

- Jonathan M Davis