Persistent list

[Andrei Alexandrescu via Digitalmars-d]

On 11/16/2015 03:38 PM, Steven Schveighoffer wrote:
> On 11/16/15 2:37 PM, Andrei Alexandrescu wrote:
>> On 11/16/2015 01:55 PM, Steven Schveighoffer wrote:
>>> On 11/16/15 1:37 PM, Andrei Alexandrescu wrote:
>>>> On 11/16/2015 12:51 PM, Steven Schveighoffer wrote:
>>>>>      List tail() const
>>>>
>>>> I'd like tail to be qualifier-idempotent, i.e. return const for const
>>>> and non-const for non-const. -- Andrei
>>>
>>> Why? const(int)[] isn't const, why should List!(const(int)) be?
>>
>> I'm keeping an eye toward other containers and also more general use.
>> It's a common need. -- Andrei
>
> Anywhere const can work, inout should work as well. The one exception as
> I've described is when you create and build a (im)mutable result, then
> converting it to const. In this case, you have to build it at once.
> Otherwise, the compiler can't tell whether this mutable thing you are
> constructing is safe to cast to inout (and whatever flavor it needs to
> cast to upon exit).

I think the main problem is the difficulty of getting from "I want to 
make this method work with mutable and nonconst data" to "I have a 
working solution using inout".

The semantics is complex and difficult. Error messages are horrifying. 
Even explaining code that works is hard. Once a solution works, trying 
to change it in meaningful ways again makes the code not work, and again 
with uninformative error messages. So there's resistance to changing 
working code.

At the same time, we have a wonderful language ready to help with 
features that didn't exist when we introduced inout. Search 
http://dpaste.dzfl.pl/52a3013efe34 for QList - it's restricted properly, 
works very well, and is easy to explain.

Walter and I think inout didn't turn out well. It became a little 
monster mastering a swamp. Template solutions can drain that swamp, make 
the monster disappear, and build nice things on that field.

I think we should slowly marginalize inout - discourage it from new 
code, document and publicize better alternatives, the works.

> In this case, it appears to work only because of your cast of _allocator
> to mutable whenever you access it via allocator. Other than that, the
> only other member is the node pointer, which is const. Effectively, A
> list's data is always const, so there is no reason to make the struct
> itself const.

Plenty of reason. The list may be member in an object. Also, if you 
don't have const List you can't compose List with itself.


Andrei