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