Persistent list

[Steven Schveighoffer via Digitalmars-d]

On 11/16/15 8:11 PM, Meta wrote:
> 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

I think it's quite clear that inout in its current form is a point of 
huge confusion. I want to work to fix this perception (and fix the 
broken corners of the implementation).

What I would ask is for those who at the moment dislike it keep an open 
mind, and hold back on your pitchforks. I need to prepare a suitable 
defense, and it's difficult to shake off the "confusing and complex" 
albatross without having sufficient time to create something that is 
easy to understand/explain for something that is conceptually simple, 
but requires a complex proof.

What I am afraid of is that someone makes a decision that something is 
bad, and by the time a good defense, or workable proposal is mounted, 
the answer is "we already discussed that, it's bad. Let's move on."

At least with this, we have a feature that is part of the language, so 
is unlikely to go away. But I'd hate to see a mob of PR requests that 
remove inout from all of phobos/druntime before I can counter this.

I think inout is worth saving, it needs a few tweaks and a good explanation.

-Steve