Does D allow paradoxical code?

[Jerry Quinn]

Daniel Keep Wrote:
 
> > 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.

That's why I'm bringing this issue up.  The spec needs to become the reliable reference rather than the DMD implementation.  Otherwise, D will be difficult to use seriously because you'll never know exactly what the language really allows.

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

I agree with you that this is a bit silly and I'm not looking to have the compiler "properly" run forever.  I'm raising the issue to get the spec to be firmer about how these meta constructs get evaluated at compile time.

Lexical order makes sense to me.  Another variant of the problem I described is if you were to mixin a protection attribute where the attribute makes the string that builds it no longer visible.

Jerry