On 03/04/12 11:24, Nick Sabalausky wrote:
"Don Clugston"<d...@nospam.com> wrote in message
news:jlecab$9gh$1...@digitalmars.com...
If you have type inference of function returns, things can get nasty:
void foo()
{
auto b() { return a(); }
X x = whatever;
auto a() { return x; }
}
Now b actually depends on the declaration of x. So it's not enough to say
that only function declarations are immune to ordering rules.
Does being inside a function really make the type deduction any harder (or
different?) than this?:
auto b() { return a(); }
enum X x = whatever;
auto a() { return x; }
Yes, it's different. In the second case, X is entirely determined at
compile time. If you have multiple declarations, there are no
user-visible semantics which are order-dependent; the value of the
expression is independent of its location in the file.
This is not true of declarations inside a scope:
eg,
static int count = 0;
int order() { ++count; return count; }
int x = order();
int y = order();
assert(x == 1);
assert(y == 2);
Furthermore, any declaration before x, which calls b(), is using x even
though x hasn't been initialized (or even declared) yet. Suddenly all
kinds of horrible situations become possible, which could never happen
before.
(Don't know if this makes any sence, but I'm throwing it out there...)
Suppose we did the approach I mentioned elsewhere in this thread: "the
compiler rewrites nested func decls as delegate vars and anon funcs".
Suppose we also use the rule:
"A nested func is not *callable* (by either the parent function *or* another
nested function) until after (ie "further down in the code") all the sibling
symbols it accesses have been declared."
Difficult but doable, but I think you end up with a really funky rule.
It's a morass of special cases.
