----- Forwarded Message -----
From: Steve Schveighoffer<[email protected]>
What I mean is, it feels like the wrong approach to ordering. I'd rather
ordering be dependent on ordering, not nesting. It seems like a
counter-intuitive way to do ordering that has the same issues using the
order of declaration.
People are going to look at some file that has static if(true) (or several
levels of them!) and scratch their heads, potentially removing it.
Are we trying to say here, ordering matters only for static ifs?
The problem isn't static if, or even ordering, per se. It's the
combination of (a) reflection, and (b) the fact that declarations can
be conditionally added via static if and mixin; the two concepts are
fundamentally incompatible.
Any reflection that checks for existence of a symbol has a result
which can change with time.
So, although the spec says that order of declarations doesn't matter, it isn't:
enum b1 = is(typeof(foo));
static if (!b2) int foo;
enum b2 = is(typeof(foo));
Is b1 true, or false? Currently, it's false, but becomes true if moved
to the bottom of the file.
You could say that any use of a non-existent symbol potentially
depends on all non-evaluated static ifs; you don't know it doesn't
exist until you've expanded them ALL.
So one idea would be to evaluate every static if that had a condition
that didn't involve reflection. If you find a condition which is
blocked, you stop, and go onto the next one. Moderately difficult to
implement, but possible.
But often you get multiple static ifs which are blocked. They are
probably independent, but you don't know. What do you do? Well, you
could arbitrarily say you do them in the order the static ifs appear
in the file.
But it's not very predictable, because you can't just look at a static
if statement and see if it is blocked or not -- the reflection could
be happening anywhere in the file. I don't think that's viable.
Then why
can't the ordering just be the order they appear? Is there any advantage to
use nesting?
The nesting behaviour is a natural consequence of saying that the
order doesn't matter. It's not a design decision. It does give an
advantage over order-in-file in the case of things like struct members
(where order in the file DOES matter) because you can control the
order the static ifs are evaluated (you can make the first static if
in the struct only be evaluated after all the others have finished).
What about some sort of pragma or @annotation to define
ordering?
That's possible, too. (That's what I meant by syntax sugar).
And what about repeatedly trying evaluating a static if until it can be
evaluated, or you are stuck? Has that been considered and rejected for some
reason?
See above. It's not feasible.
Again, not understanding all the issues, so maybe it's just the only way
possible. But it sure looks bad.
Fundamentally we're doing something which is contradictory (but so
useful in practice that we desperately want to keep it!) I think a
perfect solution is impossible.
I think we have four feasible solutions:
(1)
static ifs and mixins are expanded in the order they appear in the
file. This is applied recursively until none are left.
Finally, everything else is evaluated in parallel.
(2)
static ifs and mixins are expanded in parallel. This is repeated until
none are left.
Finally, everything else is evaluated in parallel.
(3)
Everything is evaluated in parallel, except for static ifs and mixins.
If no static ifs or mixins, quit.
static ifs and mixins are evaluated& expanded in the order they
appear in the file. Repeat.
(4)
Everything is evaluated in parallel, including static ifs and mixins
(but they aren't expanded).
If no static ifs or mixins, quit.
static ifs and mixins are expanded. Repeat.
All of these have surprising behaviour in some ways.
-Don.
