Persistent list

[Andrei Alexandrescu via Digitalmars-d]

On 11/17/2015 04:43 AM, Marc Schütz wrote:
> On Monday, 16 November 2015 at 14:45:35 UTC, Andrei Alexandrescu wrote:
>> The challenge is proving that a mutation is not observable. Got an
>> attack on that? -- Andrei
>
> Here's what I wrote a few days ago, without having read the current
> discussion, so it's not a perfect fit:
> http://wiki.dlang.org/DIP85
>
> For the case of lazy initialization, assigning a member exactly once is
> safe, if it hasn't been read and returned before. The compiler can check
> this by automatically inserting a few asserts. The rules in the DIP
> aren't completely water-tight, but they are a good approximation.
>
> But for members that have to be mutated several times (e.g. refcount),
> this obviously isn't useful. I think we can make this @system, thereby
> forcing implementors to write @trusted code and (hopefully) consider the
> consequences thoroughly. But the compiler can also assist with that. For
> example, it could detect whether a "privately mutable" value, or
> something depending on it, is returned from the function, and reject that.
>
> Maybe the implementation for the two kinds of use-cases (write once vs
> write multiple times) can be unified, too.

Thanks for the DIP, I saw it since a couple days ago. 
Dynamically-verified lazy initialization is difficult, but doesn't cover:

1. Reference count updates (as you mention)

2. The reference to the allocator is essentially a mutable part of an 
object that's otherwise constant.

So it seems to be DIP85 is solving a quite narrow problem, and one that 
doesn't address the issue at hand.


Andrei