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

[deadalnix]

On Friday, 14 March 2014 at 12:26:18 UTC, Timon Gehr wrote:
> "   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.
>

You are right. I'm updating the DIP to make it 1 indexed.

> "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.
>

Order of inclusion only matter for symbol in socpe when compile 
time construct are present. They may introduce random symbols, it 
do not seems possible to make them independent of order in the 
source code in a paradox free manner. I have no proof of this, 
and I'd be happy to be proven wrong.

You are also right, they is an hole in the proposal when it comes 
to loop in module inclusion. I still think the proposal is a huge 
improvement over the current situation.

> 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.
>

I'm not sure what you think should happen as per my proposal 
here. Both module fail at the very first conditional :
static if(foo){ mixin("enum bar=true;"); } // priority 3, 
evaluate in order, foo doesn't exists. Error.
mixin(qux); // Same here, qux do not exists, error.

> 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
> }

mixin are priority 2. mixin(xx) is processed first and is an 
error. If an xx string is defined somewhere (for instance in a 
imported module not present in the sample code) then mixin(x) 
becomes indeed an error, as it override the symbol xx, which 
would change the semantic of the previous mixin.