DIP31 (Was: Re: Bountysource: Facebook offers additional funding for D issues)

[Timon Gehr]

On 03/14/2014 02:14 AM, deadalnix wrote:
>>
>> What about fixing compile-time reflection?
>>
>> There is the notorious case
>>
>> static if(!is(typeof(e))) enum f = true;
>> static if(!is(typeof(f))) enum e = true;
>>
>> and many like it. Sometimes, compilation of the same program where
>> source files are passed on the command line in a different order
>> influences the behaviour of the produced executable.
>
> http://wiki.dlang.org/DIP31

"   3. A construct that may introduce unknown symbols.

The obvious feature of priority 2 is mixin, ..."

I think the explanation accidentally uses 0-based indexing.

"Any attempt to resolve a symbol will create a poison at the 
corresponding entry. ... Construct of priority 2 are evaluated in order 
of appearance in the source."

Order of appearance in the source is not well-defined. There can be 
circular imports. In any case, strategies dependent on declaration order 
at all do not result in predictable/flexible enough semantics in my 
opinion. One would need to reduce in parallel until analysis is 
completely stalled on lookups of unpoisoned symbols. Then one poisons 
all the stalled lookups in the topmost strongly connected component of 
the lookup-dependency-graph at once.

Eg. the following simple cases are easily seen to be completely 
unambiguous by this strategy:

// ----

static if(foo){ mixin("enum bar=true;"); }
mixin("enum foo=true;");

// ----

mixin(qux);
static if(foo.length){
     mixin("enum bar=true;");
     mixin(baz);
}
mixin("enum foo=baz;");
mixin("enum baz=`enum qux=q{enum fun=3;};`;");

static assert(fun==3);

The compiler should be able to resolve this.

Unfortunately this is not yet sufficient, eg. the following 
reasonably-looking case is not shown to be unambiguous by this strategy 
alone.

enum x = "enum xx = q{int y = 0;};";

struct SS{
     mixin(xx);
     mixin(x); // error, xx poisoned
}