[dmd-internals] Fw: Fixing forward ref bugs for good

[Rainer Schuetze]

On 9/16/2011 1:03 PM, Don Clugston wrote:
>> ----- Forwarded Message -----
>> From: Steve Schveighoffer<schveiguy at yahoo.com>
>> What I mean is, it feels like the wrong approach to ordering.  I'd rather
>> ordering be dependent on ordering, not nesting.  It seems like a
>> counter-intuitive way to do ordering that has the same issues using the
>> order of declaration.
>>
>> People are going to look at some file that has static if(true) (or several
>> levels of them!) and scratch their heads, potentially removing it.
>> Are we trying to say here, ordering matters only for static ifs?
> The problem isn't static if, or even ordering, per se. It's the
> combination of (a) reflection, and (b) the fact that declarations can
> be conditionally added via static if and mixin; the two concepts are
> fundamentally incompatible.
> Any reflection that checks for existence of a symbol has a result
> which can change with time.
>
> So, although the spec says that order of declarations doesn't matter, it isn't:
>
> enum b1 = is(typeof(foo));
> static if (!b2)  int foo;
> enum b2 = is(typeof(foo));
>
> Is b1 true, or false? Currently, it's false, but becomes true if moved
> to the bottom of the file.
>
> You could say that any use of a non-existent symbol potentially
> depends on all non-evaluated static ifs; you don't know it doesn't
> exist until you've expanded them ALL.
> So one idea would be to evaluate every static if that had a condition
> that didn't involve reflection. If you find a condition which is
> blocked, you stop, and go onto the next one. Moderately difficult to
> implement, but possible.
> But often you get multiple static ifs which are blocked. They are
> probably independent, but you don't know. What do you do? Well, you
> could arbitrarily say you do them in the order the static ifs appear
> in the file.
> But it's not very predictable, because you can't just look at a static
> if statement and see if it is blocked or not -- the reflection could
> be happening anywhere in the file. I don't think that's viable.
>
>>   Then why
>> can't the ordering just be the order they appear?  Is there any advantage to
>> use nesting?
> The nesting behaviour is a natural consequence of saying that the
> order doesn't matter. It's not a design decision. It does give an
> advantage over order-in-file in the case of things like struct members
> (where order in the file DOES matter) because you can control the
> order the static ifs are evaluated (you can make the first static if
> in the struct only be evaluated after all the others have finished).
>
>>    What about some sort of pragma or @annotation to define
>> ordering?
> That's possible, too. (That's what I meant by syntax sugar).
>
>> And what about repeatedly trying evaluating a static if until it can be
>> evaluated, or you are stuck?  Has that been considered and rejected for some
>> reason?
> See above. It's not feasible.
>
>> Again, not understanding all the issues, so maybe it's just the only way
>> possible.  But it sure looks bad.
> Fundamentally we're doing something which is contradictory (but so
> useful in practice that we desperately want to keep it!) I think a
> perfect solution is impossible.
>
> I think we have four feasible solutions:
> (1)
> static ifs and mixins are expanded in the order they appear in the
> file. This is applied recursively until none are left.
> Finally, everything else is evaluated in parallel.
> (2)
> static ifs and mixins are expanded in parallel. This is repeated until
> none are left.
> Finally, everything else is evaluated in parallel.
> (3)
>   Everything is evaluated in parallel, except for static ifs and mixins.
>   If no static ifs or mixins, quit.
>   static ifs and mixins are evaluated&  expanded in the order they
> appear in the file. Repeat.
> (4)
>   Everything is evaluated in parallel, including static ifs and mixins
> (but they aren't expanded).
>   If no static ifs or mixins, quit.
> static ifs and mixins are expanded. Repeat.
>
> All of these have surprising behaviour in some ways.
> -Don.
>

I agree with Don's compilation. I just want to point out that the 
expansion does not need to recurse into nested scopes during the steps 
above (if there are no explicite symbol lookups during condition/mixin 
evaluation). All we want is the *complete* list of symbols in the 
current scope.
Looking into nested scopes might get delayed by lazy evaluation, maybe 
even skipped in a fast compilation mode.