[dmd-internals] Fw: Fixing forward ref bugs for good

[Steve Schveighoffer]

>________________________________
>From: Don Clugston <dclugston at googlemail.com>
>To: Discuss the internals of DMD <dmd-internals at puremagic.com>
>Sent: Friday, September 16, 2011 4:03 PM
>Subject: Re: [dmd-internals] Fw: Fixing forward ref bugs for good
>
>> ----- Forwarded Message -----
>> From: Steve Schveighoffer <schveiguy at yahoo.com>
>> 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.

I understand the current issues are hairy, but I think understanding that the above b1 can change if it's moved to be later in the file is easier than understanding that:

static if(true)  enum b1 = is(typeof(foo));
static if(!b2) int foo;
enum b2 = is(typeof(foo));

the static if(true) makes a difference.  potentially, if something depends on b1, it needs 2 static ifs in order to be evaluated properly.

It seems like an "artifical" solution to being able to declare things out of oder -- you still need to follow some ordering, only now it's not sequential, it's hierarchical.  It's a lot easier for me to see what order things are evaluated when they are in some order in the file than it is to see the ordering from the level of nesting.

That's all I'm saying.  It's going to add a level of confusion, and it still seems like you need to be careful of ordering (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).

Yes, I can see why you'd want that, but that seems fringe-ish.  It's probably fixable by repeating some part of the code just for evaluating the static if, or factoring something out of the struct.

We should also be considering saying order *does* matter in certain cases.

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

I wasn't thinking of static ifs 
which depend on seeing if a symbol exists.  I agree those are 
potentially different depending on some ordering.

-Steve