Persistent list

[Dmitry Olshansky via Digitalmars-d]

On 14-Nov-2015 02:10, Andrei Alexandrescu wrote:
> I created a simple persistent list with reference counting and custom
> allocation at http://dpaste.dzfl.pl/0981640c2835. It's a good
> illustration of a number of issues. In particular, each cast must be
> properly explained.
>
> Here's my exegesis:
[snip]
> * Lines 11-12: I came to terms with the notion that some types cannot be
> made immutable. We've been trying to do reference counting on immutable
> objects for a long time. It's time to acknowledge that true immutability
> (which the immutable keyword models) and reference counting don't mix.
> Const does work (more below). But overall I'm at peace with the notion
> that if you can't live without immutable, I'll refer you to the garbage
> collector.
>
> * Lines 26-29: The allocator is fundamentally a mutable part of the
> container. This is an insufficiency of our type system - we can't say
> "this object may be constant, but this reference is to a mutable part of
> it". We can't explain that necessity out of existence, and List is part
> of the proof. So we need to make that cast legal.

Just don't make it const (see your point at 11-12). I have a feeling 
that ref-count and allocator are in the same mold - fields that must mutate.

So I imagine const/immutable for complex types will only work like this:

struct Layout{
    immutable Core core; //all constness ends here
    // accounting fields
    uint refCount;
    UAllocator alloc;
// ... any tracing and/or stats fit this definition
}

I totally do not understand the whole knee-jerk reaction of "everything 
must be const because it looks good in my code" and bug reports a-la:

const obj = SomeComplexTypeFromStd(....); // doesn't compile!

Well some types can't be transitively const (w/o sacrificing 
functionality/performance). Low-level immutable is a tool to create 
high-level immutable constructs IMHO.

It might make sense to re-purpose final storage class to be write-once 
a-la Java, because this is what folks expect when writing 
`immutable/const x = ...;` everywhere possible.

> * Lines 141-152: I couldn't make tail() work with inout. Generally I'm
> very unhappy about inout. I don't know how to use it. Everything I read
> about it is extremely complicated compared to its power. I wish we
> removed it from the language and replaced it with an understandable idiom.
>

I can't agree more. Every time dealing with inout when I finally think I 
grok how it works the next instant I see that it doesn't do what I expect.

For me inout inevitably stops at the boundary of being unnable to have 
List!(inout(T)) and the like.


-- 
Dmitry Olshansky