opApply and that int

[Bill Baxter]

I know we've been through this before but I don't recall the conclusion.

Why do we have to pass an int through our opApply functions.

Given an object.opApply that takes a delegate that takes a ref T,
and code like this:

foreach(T x; object) {
      if (x) break;
      if (condition) return Something;
      do_something;
}

the compiler transforms that into something like this:

RType _fn_ret; // (RType is return type of enclosing function)
int _loop_body(ref T x)
{
    if (x) return BREAK;
    if (condition) { _fn_ret = Something; } return RETURN;
    do_something;
    return 0;
}
int _ret = object.opApply(&_loop_body));
if (_ret==RETURN) return;
else if (_ret==GOTO) goto ??;
// maybe some other cases...


My question is this: _loop_body and the caller of opApply share the same 
enclosing scope, so why not stick the return code in a local variable 
both can see?  It already seems to do that that for return values (as 
far as I can tell from reading dmd/src/dmd/statement.c).  So why not do 
it for the main return code too and generate code like this:

RType _fn_ret;
int _ret = 0;
void _loop_body(ref T x)
{
    _ret = 0;
    if (x) { _ret = BREAK; return; }
    if (condition) { _fn_ret = Something; _ret = RETURN; return; }
    do_something;
}
object.opApply(&_loop_body));
if (_ret==RETURN) return;
else if (_ret==GOTO) goto ??;
// maybe some other cases...


Why oh why does that int have to go traipsing through *my* opApply?

--bb