inout and opApply

[Timon Gehr via Digitalmars-d]

On 20.06.2016 17:09, Steven Schveighoffer wrote:
>
> What I would like the compiler to do (and I went over this in my talk),
> is to allow the compiler to inout-wrap a delegate along with the other
> inout prameters to the function. That is, for:
>
> int opApply(scope int delegate(ref inout T value) dg) inout
>
> The inout inside the delegate is wrapped just like the inout of the
> 'this' parameter. effectively, this becomes equivalent to several
> function signatures:
>
> int opApply(scope int delegate(ref T value) dg)
> int opApply(scope int delegate(ref const T value) dg) const
> int opApply(scope int delegate(ref immutable T value) dg) immutable
> int opApply(scope int delegate(ref inout T value) dg) inout
>
> And interestingly enough, the rules are kind of backwards for delegates
> -- while inout doesn't cast to anything, delegates with inout parameters
> can cast to any type of mutability modifier (I believe this is called
> contravariance). This is because the actual function is inout, so it
> cannot harm the mutability. So something like this:
>
> foreach(inout a; anyV1)
> {
> }
>
> should work for any flavor of V1.
>
> I think this should work with existing code, and would simply open up
> things like opApply to inout support.
>
> The only issue is that the compiler has to assume that while calling the
> delegate, the inout parameters passed COULD change value, because it
> doesn't know whether the passed delegate is truly inout, or just matches
> the constancy of the type, which could potentially be mutable. This
> differs from current expectations of inout delegate or function pointers.
>
> It's a lot of complex explanation, but the end result is that you could
> simply tag your opApply's with inout and have one version for all modifiers.

The problem here is that both variants make sense depending on context 
and there is no syntax to distinguish between them. This proposal 
interacts in a weird way with IFTI.