"Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message news:mailman.100.1316815714.26225.digitalmar...@puremagic.com... > On Friday, September 23, 2011 14:54 Nick Sabalausky wrote: >> "Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message >> news:mailman.96.1316813793.26225.digitalmar...@puremagic.com... >> >> > On Friday, September 23, 2011 14:14 Nick Sabalausky wrote: >> >> "Adam Ruppe" <destructiona...@gmail.com> wrote in message >> >> news:j5iac7$2ole$1...@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.