On 6/20/16 9:55 AM, Dicebot wrote:
On 06/20/2016 04:47 PM, Shachar Shemesh wrote:
Please consider the following program:
struct V(T) {
int opApply(scope int delegate(ref T value) dg) {
return 0;
}
int opApply(scope int delegate(ref const T value) dg) const {
return 0;
}
}
struct V1(T) {
int opApply(scope int delegate(ref inout T value) dg) inout {
return 0;
}
}
void main() {
const V!int mytype1;
V!int mytype2;
V1!int mytype3;
foreach( v; mytype1 ) {
}
foreach( v; mytype2 ) {
}
foreach( v; mytype3 ) { // <- This line doesn't compile: cannot
uniquely infer foreach argument types
}
}
So the only way to get inout to work is... not to use it?
I think Steven has mentioned this issue during his DConf inout talk.
Yes, it's something I'm going to post about soon.
In essence, the delegate which takes inout parameter is currently its
own wrapping of inout. Meaning, the implicit delegate the compiler
creates does not participate in the inout wrapping for the opApply call.
Consider how this works for the compiler. I'll give you an example:
V1!int mutableX;
foreach(ref int a; mutableX)
{
a = 5;
}
Here, I've removed the type inference to set that issue aside for now.
What the compiler does is convert your foreach body into a local
delegate. This local delegate looks like this:
int __foreachBody(ref int a)
{
a = 5;
// this is added by the compiler for flow control
return 0;
}
and then calls:
switch(mutableX.opApply(&__foreachBody))
{
// process specialized returns from delegate
}
So, ignoring the special opApply machinery, we can see the fundamental
issue here is that we are passing a function pointer of type int (ref
int a) into the opApply. However, currently, the compiler treats a
function pointer with inout parameters to be simply a pointer to an
inout function. The constructed delegate cannot be this, since a is ref
int, not ref inout(int). So it cannot compile. We could change the body
to not modify a, and possibly we could create a solution, but it's not
ideal.
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.
-Steve
