Does D allow paradoxical code?

[Daniel Keep]

Jerry Quinn wrote:
> What should happen when the following code is compiled?
> 
> mixin(vs);
> version(v1) {
>   const string vs = "version = v2;";
>   pragma(msg, "yes");
> }
>  else {
>   const string vs = "version = v1;";
>   pragma(msg, "no");
>  }
> 
> Currently, there's an error saying that vs must be a string.  However, as far as I can tell, the spec says nothing about order affecting module-scope declarations.  So vs should be valid, and once it substitutes in the mixin, you have a cycle where no matter what vs is, vs should be the other value.
> 
> If you don't have the conditional compilation and put the declaration of vs after the mixin, it works as expected.
> 
> This generally raises the question of what should be the order of evaluation for constructs like mixins, conditional compilation, and CTFE.   Each has the potential to modify the other.
> 
> What should be the rule to break the ambiguity?  Or do we leave it implementation-defined?
> 
> Thoughts?
> Jerry

The D spec, as far as I know, says nothing on this.  Then again, the D
spec says nothing about a lot of things it should.  Personally, I just
ignore the spec; DMD is the only reliable reference for the language.

Now, being as I'm supposed to go off and do my walk around the block
now, I'll be lazy and start making educated guesses.  I don't think the
DMD frontend is smart enough to handle this; nor do I think it should.

If you were to allow this sort of thing, you'd never be able to bloody
well compile it.  The simplest solution is to simply make canonical what
I think DMD already does: static code [1] can be arranged in any order
[2], but meta code [3] is processed strictly in lexical order.

Indeed, version actually already does this: you're not allowed to set a
version after you've already used it.


[1] being code which doesn't contain any meta code.

[2] this statement, of course, this is complete garbage; work with enums
for any length of time and you'll quickly discover "D supports forward
references" is a dream at best.

[3] being anything which generates static code; static if, foreach over
a tuple, templates, mixins, etc.