On Wed, Feb 13, 2019 at 11:32:46AM +, envoid via Digitalmars-d-learn wrote:
> In C++ we have const correctness in some way. A compiler can make
> optimizations whenever it doesn't find a const_cast and the mutable
> specifier marks members that aren't a part of the object state. Of
> course, it's not perfect but one can document their intentions and
> it's possible to use synchronization primitives without an issue. On
> the opposite side, D has a stricter (transitive) const and it's almost
> useless in many cases. Is there an article that explains best
> practices of using const in D? The statement "In C++ const isn't
> transitive so we fixed that." alone isn't convincing. The only way I
> see right now is omitting the const keyword completely which is
> ridiculous.
Const in D is very restrictive because it's supposed to provide real
compiler guarantees, i.e., it's statically verifiable that the data
cannot be changed.
Unfortunately, that guarantee also excludes a lot of otherwise useful
idioms, like objects that cache data -- a const object cannot cache data
because that means it's being mutated, or lazily-initialized objects --
because once the ctor has run, the object can no longer be mutated. Most
notably, D's powerful range idiom is pretty much unusable with const
because iteration over a range requires mutating the range (though
having const *elements* in a range is fine). This doesn't seem as bad
at first glance, but it wreaks havoc on generic code, another thing that
D is purportedly good at. It's very hard (and often impossible) to write
generic code that works with both const and mutable objects.
In practice, I've found that using const is really only sustainable at
the lowest levels of code, to guarantee low-level non-mutability of PODs
and other low-level objects. It's also useful for representing a
reference to data that could be either mutable or immutable, in this
"type inheritance" diagram that's very helpful for D learners to
understand how D's const system works:
const
/ \
mutable immutable
I.e., mutable and immutable are implicitly convertible to const, but
const is not implicitly convertible to either. Immutable in D is a hard
guarantee that the data cannot ever be changed by anyone in any thread.
Const means the holder of the const reference cannot mutate it, but a
3rd party could possibly hold a mutable reference to it and mutate it
that way. So it's a somewhat weaker guarantee. But that's beside the
point. The point is that when your code doesn't touch the data but you
want to be able to pass both mutable and immutable arguments to it,
const is the ticket.
But given the restrictiveness of const, it's a rare occasion when you
actually have to do this. The most notable exception being D strings,
which are defined to be immutable(char)[], i.e., a (mutable) array of
immutable chars (meaning the array itself can be changed, e.g., by
slicing, changing length, etc., but the underlying char data is
immutable). Some of my own projects use const(char)[] quite often, in
order for the code to be able to accept both mutable char[] and string
(i.e., immutable(char)[]).
Outside of this, I only use const rarely, maybe in the occasional query
method in a low-level type where I'm sure mutation will never be
necessary. Even in such cases, I rarely use const, because it's
infectious and a seemingly small change of adding const to a getter
method sometimes percolates throughout the entire codebase and requires
const correctness everywhere else, usually ending in a stalemate when it
reaches something like a range that needs to be mutable and cannot be
made const without onerous refactoring. It's *possible* in theory to
make everything const-correct, but it's quite onerous and honestly only
of limited benefit relative to the sheer amount of effort required to
pull it off. So most of the time I just don't bother except in the
lowest levels of code where the scope of const's infectiousness is
limited.
So ironically, the iron-clad semantics of D's const system turns out to
be also its own downfall.
T
--
Obviously, some things aren't very obvious.
