Persistent list

[Meta via Digitalmars-d]

On Tuesday, 17 November 2015 at 00:30:39 UTC, Steven 
Schveighoffer wrote:
> 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

I don't mean to derail this thread, but I also am not really 
crazy about inout in its current form. Its transitive nature is 
one issue (though that can't be changed due to const and 
immutable also being transitive), but also the fact that inout is 
basically a fourth qualifier, which causes a lot of pain when 
you're wrapping other types.

For example, calling opEquals on a wrapped struct inside the 
opEquals of the wrapper struct (which is marked as inout) when 
the wrapped struct does not also define an inout opEquals, will 
not call the mutable opEquals of the wrapped struct. It *will 
not* compile unless the wrapped struct also defines an inout 
opEquals, no matter the constness of the wrapper or the wrappee. 
Basically, wrapper types cannot with inout.

http://stackoverflow.com/questions/31516713/escaping-from-inout-hell