Persistent list

[deadalnix via Digitalmars-d]

On Tuesday, 17 November 2015 at 00:30:39 UTC, Steven 
Schveighoffer wrote:
> On 11/16/15 6:56 PM, deadalnix wrote:
>> On Monday, 16 November 2015 at 22:30:55 UTC, Andrei 
>> Alexandrescu wrote:
>>> On 11/16/2015 05:02 PM, Jonathan M Davis wrote:
>>>> It's just that you use inout instead of const. How is that 
>>>> worse?
>>>
>>> The short answer is my perception is inout is too complicated 
>>> for what
>>> it does. -- Andrei
>>
>> I'm happy to read this. inout has the wrong cost/complexity 
>> ratio. It
>> doesn't solve the problem generally (one want to return type 
>> depending
>> on argument qualifier in general, not only for type 
>> qualifiers) while
>> having a high complexity.
>>
>
> The problem it solves is to provide a mechanism that allows one 
> to safely apply the same qualifiers to the return type, but 
> have the inputs be constant *throughout the function*.
>
> A templated function doesn't do this, you can have conditional 
> code, or unchecked method calls that can modify the data when 
> possible.
>
> Of course, if this isn't important, then the template solution 
> is usable. My take is that whenever you use inout is when you 
> would normally use const, but const doesn't allow what you 
> need. If your function doesn't need const inside the function, 
> then you shouldn't use inout.
>
> To me, it feels like inout is simple, but the implementation 
> has warts that make it seem inconsistent. There is also the 
> issue that nested inout is super-confusing, because now you 
> have layers of inout, each layer meaning possibly something 
> different. If we could somehow fix the nested part (and allow 
> types with inout members inside there), I think inout would be 
> less intimidating.
>
> -Steve

Here is, IMO, the point you are missing.

There many qualifier you'd like to have depend on other 
qualifiers. For instance :

void doSomeThingAndCallBack(maybe_pure void function() callback) 
pure_if_maybe_pure_argument_is_pure {
     callback();
}

You'll note that this is the same problem as inout solves. Thing 
is inout is complex, but only solve a small subset of the problem.

Thus, the power/complexity ratio is not good.

Also, yes, the implementation is B0rken :) Still it has gotten 
much better over time (or I learned the hard way to stay into the 
patterns that works ?).