Why version() ?

[Walter Bright]

bobef wrote:
> I was thinking... what is the point of version() ? It is so
> inflexible. There is no even version(!...). Why not "static
> if(version(DMD))" or static if(is(version == DMD))?

The version statement is designed to be inflexible. It's designed to 
encourage abstracting and modularizing version differences, rather than 
encouraging line-by-line differences.

I've used #if/#endif for decades. Over time, it *always* degenerates 
into an utter rat's nest of nested, incomprehensible complexity (and 
this includes my own code). For a lovely example of how bad it can get, 
take a look at the source code to Hans Boehm's garbage collector. I defy 
anyone to figure it out without running the code through the 
preprocessor first to see which statements are actually getting compiled.

A far better way to do versioning is to find the abstraction lines 
separating versions, and put version specific code in separate modules 
that are then imported. It makes for nice, clean, understandable code.

Static if can be used for version control, but that is not what it's 
for. Static if is for use inside templates to control code generation 
based on template parameters, not for producing different versions of 
the program.


1. Why not version(!feature) ?

Because cognitive studies show that people just don't see the negation. 
Secondly, when you see things like:

     version (!linux) { ... }

they're almost always wrong. Versions should be positive things, because 
a version is something that is being build - one doesn't craft a 
makefile to build a notLinux.

2. version (A || B) can be done as:

     version (A) version=AorB;
     version (B) version=AorB;

3. version (A && B) can be done as:

    version (A) version (B) { ... }

though if you find yourself doing that a lot, I suggest abstracting away 
the A and B version into its own AandB version.

4. Conditional compilation can be done with version(all) and version(none).

5. Why can't one 'version out' syntax that is not recognized by the 
compiler?

The problem is that supporting this requires semantic analysis in order 
to successfully lex and parse the source code. Breaking this will make 
the lexing and parsing an order of magnitude harder for third party 
tools to do. If you need to 'comment out' a section of syntactically 
invalid code, use the /+ ... +/ nesting comment.