What does D define for circular dependencies

[Timon Gehr]

On 06/26/2012 07:27 PM, Mehrdad wrote:
> I realize this scenario might look stupid, but I hope the underlying
> problem isn't.
>
> Does D define what happens in a situation like this?
>
>
> module a;
> import b;
> static if (!is(typeof(.b.foo))) int foo = 1;
>
>
> module b;
> import a;
> static if (!is(typeof(.a.foo))) int foo = 2;

I have brought up similar examples in the past. Compilation should
fail. There is no specification on what is legal code and what is not 
yet. (the obvious answer 'code is illegal if it is contradictory or
ambiguous' makes compilation undecidable.)

A way to solve the issue is to keep record of what symbol lookups
failed in what scopes and to issue an error if a symbol is introduced
that was previously decided to not exist. Symbol lookup proceeds as
repeated fixed point iteration, where at the end of an iteration, some
symbols that are still unresolved are decided to not exist.
Simple heuristics can be applied to guide analysis in a way that is as
precise as possible. (Eg. analyze what kind of symbols can be
introduced by which declarations and always focus symbol resolution on
the top connected component of the potential-lookup-dependency graph.)

Special care has to be taken for overloads of the same symbol name:

int foo(double x){}
static if(is(typeof(foo(1))==int) double foo(int x){}// error

Another issue is how to treat stuff like this:

struct S{
     int somemember1, somemember2;
     mixin(generateSomeMoreDeclarations!(__traits(allMembers, S)());
}

Ideally this would be legal, but it becomes non-trivial quite fast.