Dicebot on leaving D: It is anarchy driven development in all its glory.

[H. S. Teoh]

On Tue, Aug 28, 2018 at 07:39:20PM +0000, tide via Digitalmars-d wrote:
> On Tuesday, 28 August 2018 at 17:02:46 UTC, 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.  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.
> 
> I feel that such a narrow use case, wouldn't you just use something
> like immutable instead.

The problem is that immutable implicitly converts to const.  Basically,
const means "I guarantee I will never modify this data (though someone
else might", and immutable means "nobody will ever modify this data".
You cannot allow const to mutate without risking breakage with
immutable.  If the original data came from a mutable reference, you can
probably get away with casting const away. But if it came from an
immutable object, casting const away is UB.  Allowing const to be
"sometimes" modified is also UB.


> > 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).
> 
> This is still not true, it is not machine verifiable as it is. It can
> be bypassed quite easily, as a const object can be assigned from an
> non-const one. There's no way to offer that guarantee.

You misunderstand. Const means "this code cannot modify this object no
matter what".  It does not guarantee somebody else can't modify it (you
want immutable for that).  Both mutable and immutable implicitly convert
to const, therefore it is imperative that code that handles const never
modifies the data, because you don't know the provenance of the data: it
could have come from an immutable object.  Allowing const to "sometimes"
modify stuff will violate immutable and cause UB.

Whether a piece of code modifies the data is certainly
machine-verifiable -- but only if there are no backdoors to const. If
there are, then the compiler cannot feasibly verify const, since it
would need to transitively examine all code called by the code in
question, but the source code may not be always available.

Even if the data came from a mutable object, it does not make it any
less machine-verifiable, since what we're verifying is "this code does
not modify this data", not "this data never changes".  For the latter,
immutable provides that guarantee, not const.  It is possible, for
example, to obtain a const reference to a mutable object, and have one
thread modify the object (via the mutable reference) while another
thread reads it (via the const reference).  You cannot guarantee that
the data itself won't change, but you *can* guarantee that the code
holding the const reference (without access to the mutable reference)
isn't the one making the changes.


T

-- 
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the potential for it to be applied to tasks that are
conceptually similar and, more important, to tasks that have not yet
been conceived. -- Michael B. Allen