Persistent list

[Marc Schütz via Digitalmars-d]

On Monday, 16 November 2015 at 16:58:24 UTC, Lionello Lunesu 
wrote:
> On 16/11/15 22:45, Andrei Alexandrescu wrote:
>> The challenge is proving that a mutation is not observable. 
>> Got an
>> attack on that? -- Andrei
>
> Forgive me, I haven't followed the RC discussions closely, so I 
> miss a lot of context. Feel free to point me to existing 
> threads/articles.
>
> If it's RC we want, then @mutable is an axe when what we need 
> is a scalpel.

It has additional uses, though, e.g. memoizing and  lazy 
initialization of members.

>
> The non-observability comes from the fact the refcount is 
> changed when the caller has lost its (const) reference and 
> constness is a moot point. Changing refcount is fine now, 
> provided the object is not immutable. As far as other 
> outstanding const references go, these already expect changes 
> to happen.

Refcount also needs to change when you get an additional 
reference. But it is non-observable, because the caller can't 
access the refcount directly (or we could allow it, but as 
@system). The only potentially observable side-effect would be if 
the object is destroyed, but this only happens if there are no 
references left. Then the only way this can be achieved is if the 
destructor modifies state that is otherwise accessible (global, 
or by references), which however is not a problem, because the 
normal rules of const-ness apply to it.

>
> This is what makes refcount special and provably safe to 
> mutate. As long as we can ensure the object is not immutable, 
> the object is allowed to change its own refcount. But refcount 
> needs to be special cased, somehow, or else we'll end up with 
> some C++ like `mutable`.

But the point is that we _want_ to have refcounted immutables, 
too, not just refcounted consts.