version vs. static if

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.100.1316815714.26225.digitalmars-d at puremagic.com...
> On Friday, September 23, 2011 14:54 Nick Sabalausky wrote:
>> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
>> news:mailman.96.1316813793.26225.digitalmars-d at puremagic.com...
>>
>> > On Friday, September 23, 2011 14:14 Nick Sabalausky wrote:
>> >> "Adam Ruppe" <destructionator at gmail.com> wrote in message
>> >> news:j5iac7$2ole$1 at digitalmars.com...
>> >>
>> >> >I hope there's no D3 for a very long time. Maybe 2020.
>> >>
>> >> I still hope there is one at some not-too-distant point, though. The
>> >> whole
>> >> version system really does need an overhaul. One of the big things, if
>> >> not
>> >> the key one, is that basing it on "symbol defined" vs "symbol not
>> >> defined"
>> >> (rather than a compile-time bool) is far too problematic.
>> >
>> > That's by design. That's the way that Walter wants it. I wouldn't 
>> > expect
>> > that
>> > to change in any future version of D unless you can come up with a 
>> > really
>> > good
>> > argument to change Walter's mind or someone else takes over as the
>> > benevolent
>> > dictator at some point.
>>
>> Really? I had no idea. What's the reasoning? (I honestly can't imagine
>> anything.)
>
> I believe that it comes down to complexity. In C and C++, you get stuff 
> like
>
> #if COND1 || COND2 || (COND3 && COND4)
>
> and it can become fairly easy to screw up when you manage versions that 
> way -
> especially when each of those conditions can be arbitrarily complex _and_ 
> they
> can be affected in entertaining ways by whatever #includes you happen to 
> have
> before them. Simply adding or removing a #include could completely change 
> the
> result of such conditions (as could reordering them in some cases).
>
> By having version restricted to what's defined and having it unaffected by
> imports, it simplifies the situation considerably.
>

But version is *not* restricted to what's defined. It *also* deals with 
what's *not* defined. That's the main problem I'm talking about.

If Walter wants to limit the logic operations and import implications, none 
of that necessitates that the version identifiers be based on "defined vs 
undefined".

What I mean is this: Using an undefined version identifier should be an 
error:

version(ThisIsNeverDeclaredAnywhere) {} else {}

That is currently accepted, but it should be a compile-time error.

If you want that to work, you should be forced to do one of the following:

// A:
version ThisIsDeclared = true;
version(ThisIsDeclared) {} else {}

// B:
version ThisIsDeclared = false;
version(ThisIsDeclared) {} else {}

// C:
version(ThisIsDeclared) {} else {}
>dmd foo.d -version:ThisIsDeclared


// D:
version(ThisIsDeclared) {} else {}
>dmd foo.d -version:ThisIsDeclared=false  # or 
>maybe -versionoff:ThisIsDeclared


Obviously you wouldn't need to (or be allowed to) declare any of the 
built-in version identifiers like Windows. They would be always be implicity 
declared and set to either true or false.