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.
