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

[tide]

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.