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.
