Persistent list

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Mon Nov 16 16:30:39 PST 2015


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


More information about the Digitalmars-d mailing list