What does D define for circular dependencies

[Mehrdad]

On Tuesday, 26 June 2012 at 18:05:38 UTC, Timon Gehr wrote:
> 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.


Cool, that answers it perfectly. Thanks!