On Tuesday, 28 August 2018 at 20:32:29 UTC, H. S. Teoh wrote:
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
Point being, there is a huge difference between what you were
saying, and what you are saying now. "This data never changes" is
a much better guarantee and check than "this code does not modify
this data". You use const to make sure the data doesn't change,
if you can't guarantee it doesn't change from any other code then
I wouldn't say it is machine-verifiable.
So we would need another qualifier "tantamount" to be implemented
then it seems.