On 03/14/2014 11:50 PM, deadalnix wrote:
...
"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.
...
It can be done. (What I described above works strictly better than the
DIP afaics.)
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:
...
I'm not sure what you think should happen as per my proposal here.
I think per your proposal, those would fail, but I think they should be
valid, as they can be processed and proven unambiguous by a reasonably
simple and quite general order-independent strategy.
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.
Yup.
