On Tuesday, 28 August 2018 at 07:53:34 UTC, Walter Bright wrote:
Let's take the much-maligned D const. It isn't C++ const (let's
call that "head-const", because that's what it is). Head-const
for a function parameter tells us very little about what may
happen to it in the function. You can pass a head-const
reference to a container, and have the function
add/change/delete every element of that container, all without
a peep from any C++ tool. Looking at the function signature,
you've really got no clue whatsoever.
The reason people have trouble with transitive-const is that
they are still programming in C++, where they *do*
add/change/delete every member of the "const" container.
That includes me. I try to add transitive-const, and it won't
compile, because I as well am used to replacing the engine and
tail lights in my head-const car. In order to use
transitive-const, it's forcing me to fundamentally re-think how
I organize code into functions.
For example, dmd is full of functions that combine
data-gathering with taking-action. I've been reorganizing to
separate data-gathering and taking-action into separate
functions. The former can be transitive-const, maybe even pure.
And I like the results, the code becomes much easier to
understand.
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?