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.
