Persistent list

[Timon Gehr via Digitalmars-d]

On 11/14/2015 10:59 PM, Andrei Alexandrescu wrote:
> On 11/14/2015 03:55 PM, Timon Gehr wrote:
>> On 11/14/2015 12:10 AM, Andrei Alexandrescu wrote:
>>> ...
>>> * 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.
>>> ...
>>
>> I.e. you think it is fine that there can be no list of lists.
>
> T may be const in List!T, so composing with const should work fine.
> ...

List uses RC internally. I don't think the UB casts will stay for the 
final version, unless you are willing to completely dilute the meaning 
of const in ways that Walter has explicitly expressed will not be done 
in the past.

>> Anyway, the static assert does not actually do what you intend it to do.
>
> The odd thing is it does as far as I can tell, but the error message is
> less than informative. Try it!
> ...

I cannot get the list to compile with 2.069.1 without replacing the 
calls to emplace, which is odd (as it works on dpaste), but in any case, 
the static assert is a no-op. typeof(this) is always unqualified at 
aggregate scope. What is preventing the construction of a non-empty 
immutable list is that there is no immutable non-default constructor.


>>> * 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 the method const. (This is not C++.)
>
> I want to allow mutable lists and const lists, just not immutable lists.
> It seems to me const has a value even if it doesn't originate from
> immutable.
> ...

It's supposed to guarantee that the given reference is not used to 
transitively mutate the object. The casts violate this.