Persistent list

[Dicebot via Digitalmars-d]

On Sunday, 15 November 2015 at 17:42:24 UTC, Jonathan M Davis 
wrote:
> On Sunday, 15 November 2015 at 15:20:24 UTC, Dicebot wrote:
>> On Sunday, 15 November 2015 at 15:09:25 UTC, Jonathan M Davis 
>> wrote:
>>> After the call to bar, the compiler can guarantee that the 
>>> value of foo has not changed, because it's not possible for 
>>> bar to access foo except via a const reference, and it can 
>>> clearly see that, because it can see that it's not possible 
>>> for bar to access foo except via the reference that's passed 
>>> to it.
>>
>> Note that it can only do so if escape analysis is able to 
>> prove no other reference escapes to the same data. Otherwise 
>> it can be mutated even during that function call in other 
>> thread.
>
> Except that shared isn't involved here. The objects are 
> thread-local, so other threads don't matter. The combination of 
> TLS and pure does make it so that the compiler could 
> theoretically do optimizations based on const. immutable is not 
> actually required, though it obviously provides far better 
> guarantees.

Ok, agreed about threading part (though does currently spec 
require all non-TLS data to be qualified as shared?). But same 
applies to fiber context switches too (within same thread). 
Basically anything that can cause extra code to be executed 
between target function start and finish requires escape analysis 
to justify such optimization.

> But my point was that there _are_ cases when the compiler can 
> do optimizations based on const without immutable being 
> involved, even if they're rare.

If they are that rare, probably they are not worth the trouble :) 
Or should be mentioned in spec explicitly (i.e. pure case)

> The primary benefit of making it undefined behavior to cast 
> away const and mutate is that then you actually have the 
> guarantee that an object will not be mutated via a const 
> reference. You get actual, physical const. As long as there's a 
> backdoor out of const, const provides no real guarantees.

No, not at all. It vast majority of cases (and pretty much all 
library code) you must assume that const can be immutable and 
thus is must be treated as physical const (because immutability 
is physical). In rare cases where it is possible to prove/ensure 
mutability of the data it makes no difference because you can 
have the backdoor via cast anyway, it will only affect how 
reliable result will be across different compilers.

> Now, given how incredibly limiting physical const is, maybe we 
> should be more lax with D's const, but if we are, we lose out 
> on the compiler guarantees that we currently get and basically 
> end up with a transitive version of C++'s const (except that we 
> have the added risk of mutating an immutable object if we're 
> not careful).

No, I think concept of physical const/immutable is fine as it is. 
Limiting but valuable for multi-threading, requiring to build 
whole design of your application around it. It just happens that 
language sometimes forces handling const even in cases you don't 
need to care about immutability (earlier invariant example) which 
makes casting it away (at least temporarily) only practical 
option - and it would be very unpleasant to have that UB.