"James Miller" <ja...@aatch.net> wrote in message
news:mailman.1324.1333434077.4860.digitalmar...@puremagic.com...
>
> [...]the issue
> is with closures, what values should be visible to the closures?
Personally, I don't much care ATM. Either way has it's pros and cons:
A. Same as right now: The nested function can only access variables defined
before it. Only difference is that it can *also* access "sibling" nested
functions that are defined before *or* after. The benefit is that there's
minimal change to the current "sequential visibility".
B. Let nested funcs access *any* "sibling" symbol whether defined before or
after. Presumably, the nested func would not be *callable* until after all
the sibling symbols it accesses have been declared. The downside is that, I
suspect, this might be more work to implement. The benefits are that it
provides more flexibility and is more consistent with module-level
declarations. That latter benefit would be import for code like this:
void main() { mixin(import("script.d")); }
I guess I would lean more towards "B", but it is a bigger change and I
realize bigger changes meet bigger resistance at this point. So I'd be
content either way because what's *more* important here is we ditch the
(seemingly) silly restriction of "no mutually recursive nested funcs".
'Course, another approach would be to just for the compiler to treat this:
void foo()
{
/+ code 1 +/
void a() {...};
/+ code 2 +/
void b() {...};
/+ code 3 +/
}
Like this:
void foo()
{
void delegate() a;
void delegate() b;
/+ code 1 +/
a = () {...};
/+ code 2 +/
b = () {...};
/+ code 3 +/
// Except that, naturally, a and b cannot
// be re-assigned by the programmer,
// and foo itself cannot access a or b
// before the "a = ...;" and "b = ...;" lines
// respectively.
}
This maybe makes the most sense, because nested funcs and
anon-funcs-assigned-to-a-variable *are* so very similar anyway. But then
again, this comes with the downside of "void main() {
mixin(import("script.d")); }" causing strange semantics inside
'script.d'...but I guess such strange semantics in 'script.d' would be the
case even without any nested funcs involved.
Actually, this might be equivalent to approach "A" above.
