Persistent list

[Steven Schveighoffer via Digitalmars-d]

On 11/16/15 8:21 PM, deadalnix wrote:
> 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.
> 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();
> }

This already works with templates. If all you care about is writing a 
function that has the *ability* to take any kind of input, then 
templates are perfect for that.

What inout solves above templates (and note, you can combine inout AND 
templates), is that during the function call, the parameter is not 
modified -- guaranteed by the compiler (as much as it can). Templates 
cannot offer that. To me the maybe_pure solution doesn't even come close 
to inout's utility (what does it guarantee beside being able to take 
different types of parameters?).

For those who care about const or try to use const (and immutable) to 
provide API guarantees on parameters, it becomes unwieldy to both 
specify "yes! I can take any qualified type of parameter" and "no! I 
promise I won't modify them." Const fills this void, but has the the 
issue of blindly coloring everything const, locking up all your data for 
things like function chaining. Inout is supposed to fix this one 
problem, and should be a seamless replacement for const in those cases. 
It obviously is not.

> Thus, the power/complexity ratio is not good.

inout is for one specific thing, I see it to be unrelated to templates. 
It's more of an extension of const. The complexity, IMO, is not 
necessarily huge (perhaps in the current implementation, I'm not sure), 
but the consistency is terrible. There are things you just should be 
able to do, and the compiler won't do them. Inevitably, the templates 
people write end up trying to do these things (because they are 
logically correct), and the compiler spits out cryptic "cannot call this 
function" errors. These can be difficult to figure out.

> 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 ?).
>

It has definitely gotten better over time. It used to be that if you 
used any kind of template with an inout parameter, it wouldn't compile.

-Steve