Stepping back and looking at constness from another angle.

[James Dennett]

Walter Bright wrote:
> 
> 1) Just as in C++, you can pretty much ignore final, const, and
> invariant if they don't appeal to you. I don't bother using const in my
> C++ code.

But there are things in C++ that don't work if you
ignore const.  You can't bind a reference (to non-const)
to a temporary, for example.  You can't use your types
in standard containers if their copy operations don't
use const-qualified references to their source objects.
You can't use symbolic constants for array sizes, or
otherwise at compile time, if you don't make them const
(or abuse enums for this purpose).  You'll be unable
to use all manner of interfaces if you ignore const.

If you write within a very limited subset of C++, you
can *then* ignore const -- but in that case you've
already let it have a huge influence of your style.

If you're writing libraries in C++ and you don't use
const, you make it impractical for users of your library
to use const, hence reducing its likely user base to
those who don't use C++ in what is widely considered to
be an idiomatic way.

This is relevant here because in C++ the choice of
avoiding const comes with significant costs (that most
find prohibitive).  It's woven into the fabric of the
language and its standard library.

D might be able to do better in allowing users to choose
whether to use a const-aware style or not.  If it does,
the community will then have to choose what style(s)
prevail.

(My personal preference would be for an enriched type
system that supports const-ish things, but that's not
what this post is really about.)

-- James