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
}
