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;

On Tue, Jun 26, 2012 at 07:27:00PM +0200, 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;

IIRC, according to TDPL, this is a compile-time error.


T

-- 
If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen

On Tuesday, 26 June 2012 at 17:27:01 UTC, 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;

Yes, TDPL describes similar cases in detail, and I'm sure that D specification does, too. Compilation should fail.

On Tue, 26 Jun 2012 13:27:00 -0400, Mehrdad <wfunction@hotmail.com> 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 don't think it can.  D does runtime circular dependency checking at a very coarse level, but this is forcing static checking.  I think the compiler will throw a forward reference/recursion error in this case (and if it doesn't, it should).

-Steve

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.

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!