Conditional compilation

[Charles]

Starting from the end

P.S. The title for this thread is weird. This isn't about extending the @help concept. It's about new directives for conditional compilation.

If you reread the earlier posts you'll see its more about using the keyword + line (extended to a block) syntax structure concept to provide conditional compilation (rather than an extension to help per se)

As you say: "...provide conditional compilation." So "Conditional compilation" would be a better title for this thread, rather than naming it after the syntax.

This is as opposed to implementing the same C-like preprocessor-ancestry general purpose variable set-unset and test branching structure. The problems issues and pitfalls of this are well known and later languages have all moved away from that concept ( at varying rates..)..

C# and D both support it. Python gets it for free as a purely interpreted language with late binding on almost everything. They just use their own if statement.

Who is moving away from it?

Actually this is all based loosely on D ( version2 of the lang rather than the 1.0 ref you linked to - not that theres very much difference/change)

Do you plan on supporting a true static-if then that has access to constants and type info?

Now to your points:

No OR / or ELSE

thats because theres no explicit 'if' or <condition>.

That's like if I said "that car has no steering wheel" and someone said "that's because we didn't put one in." Btw, D does have "else" for their "ver". Maybe what you really meant was what you said next:

This is more oriented around a block (or statement or decl(s)- dont worry about the granularity)
thats triggered from a (fixed) condition tag - Its definitely not directed towards arbitrary complex use as a general purpose branch-with-attendant-conditions setup

Well it's a special, limited case of "branch-with-attendant-conditions setup" with no benefits that I can see:

# one line of overhead:
@ver DEBUG
    print 'some debugging code'
# still simple with @if:
@if DEBUG
    print 'some debugging code'

But @if could express things that @ver will never be able to express. I consider that a good thing. (And yes I switched from the .defined('FOO') in my last post to simply FOO.)

The 'conditional' in conditional compilation here is more to 'match' to a situation
( on a particular platform/backend, match to a user setting or a compiler setting) than a binary test of a boolean expression

env.var.'value' re other comparisons

there are no other comparisons - it matches or it doesnt.

Well sometimes people want the opposite of match. With no "not" and no @else, you could be stuck.

(The number versioning was an afterthought - not sure its necessary or if need comparison to version numbers'
but could be done a similar way with something modifying what a match means

Code: Select all

env.OSVer.'>=1.0'


as a rough (and poor) example.

It will be necessary eventually when we make an incompatible change to Cobra, but some open source project wants to compile on both versions.

This is version as in any conditional compilation makes a different version of the executable.
- version for jvm
- version for mono
- version for windows, ...

So no it doesnt describe the mechanism being tested/used, it describes the goal.
'a version specific to something'

I see. Thanks for the clarification.

- I'd say static-if in D was more for the benefit of their version of templating than conditional-compilation in that it tests compile time constants and a condCompile is directed by setups/config outside the codebase (target platform, user spec build defn passed into compiler,...)

It's also your escape hatch when you need OR, AND or a comparison in your version() ... which does not support such things.

.. description for reinvention of same-old C-preprocessor-like-ifdef for cobra elided....
I dont believe this is a desirable way to go for the most common cases
(code selection for platform, back-end, Debugging, compiler-setups).
At the very least its overly general purpose and complex for the need desired and subject to the same old problems and abuses...
Cobra deserves something simpler and clearer which tag-match-and-block definitely is.

The common case is quite simple:

@if JVM
    <some code>
# and if we want a one liner, we could entertain:
@if JVM, <some code>

...alternatively compiler could expose major feature items as condCompile match tags same as doing for platform/backend tags
(hasLambda, hasMethodInference, hasLiteralCollectionTyping...) assuming we can get some agreement of what constitutes a new major feature.

Regarding the back-ends, my observation is that words like "lambda" don't give you enough info. For example, if you jot down the characteristics and rules for C# lambdas and Python lambdas, you get different lists. Otherwise, capability-based flags would be nice.

I agree that condCompile directives are not arbitrarily positionable - my impl has them only recognised in 3 places
(at statements, BoxMember decls, NSMember decls) - they're not separate from the tokeniser and recognised as unique parser items.

We agree on something!

Also, any implementation needs a lot of tests. I found a couple bugs in Cobra just the other day. I'm trying to resolve this situation and get to 1.0 by emphasizing fixes over new features. Adding new features introduces new bugs. Lots of tests will be required

yeees.. There are tests with this covering all the inflection points as per usual - adding 'lots' probably wont improve coverage appreciably. This is same situation as everywhere else.
I'm not sure of your point here: ...

I'm just wary of adding a new feature when the last new bug I found was yesterday.

However, I realize that this is sorely needed for multi-back-end work.

I would get @if working first and add convenience forms conservatively.

Aaah - I'm coming from the opposite position.
The 'convenience' forms (as you describe them) aren't - they are are the most-used core for condCompile (at least as it is now).
Only provide @if-@then-@else more general form for situations where the tag-match-and-block forms are totally unworkable.
(I'm not convinced thats the case or that the general form is advantageous in any form)

What do you mean "only provide"? As soon as you provide @if/@else then it's available in general.

And when used in simple cases, it looks simple. And when you need something more, you use the same @if with a richer condition.

re OpSys.
For comparison most of the predefined version Identifiers in D are for specific OPSys implementations ( e.g Solaris vs 'unix')
cobra (currently) only supports 3 families (windows, mac and unix)
Will we (eventually perhaps) also need to become exactly platform/hardware/... specific for these builtins also (systems programming)?

We'll need CLR and JVM version numbers. I doubt Cobra will become popular for systems programming. It seems destined for application programming which is what I originally intended anyway.

Using @if/@else if/@else and expressions as a foundation seems fundamentally useful and clear

We're agreed on fundamentally useful (some form of condCompile). Clear - no
tagged-match and block-code is definitely clearer, cleaner and also stands out from cobra exec code (compared to cobra if-else branching).

Then we're still in disagreement. You seem allergic to the #if/#define approach found in C# and other languages, but I'm not. You admit it will be needed in some situations.

But then if that's case, I don't see the need for @ver and @debug.

I'll post the patch on the ticket and you can see some condCompiled test code.

I asked some specific questions in my earlier post - those were some directions I was wondering about since I thought I'd already clarified the general approach I was heading with this earlier.

(this is probably enough of a post for now - more later if I come up with anything else).

Same here.

I looked at the patch. But after that and our discussion, I'm still favoring:

@if, @else if, @end, @define, @undefine
cobra -define

And yes, I think your list of setups is a great one to start with. I've added a couple more:

CLR, CLR20, CLR40, JVM, JVM16, JVM17, JVM18, OBJC, DOTNET, MONO, WINDOWS, UNIX, MAC, ASSERTS, TESTS, CONTRACTS, DEBUG, DST, ERT
... or we could go all lower case:
clr, jvm, objc, dotnet, etc.

dst = -detailed-stack-trace
ert = -embed-run-time

Btw the other thing that bugs me about @ver is that it doesn't just check for the existence of the symbol, it also has a matching option. Like it's trying to be a half-baked @if.

With "@if FOO" being so simple and "@ver" not being any simpler, plus trying to be like @if with its matching ability, I don't see any need for it. It's adding another way to do something without any benefit that I can identify.

[hopscc]

If the existing thread title is offensive feel free to change it or move the discussion to a new 'correctly' titled topic.
It is what it is due to what triggered the original posting which makes sense to me at least..

C# and D both support it. Python .... They just use their own if statement

no, C# supports a cut down/streamlined/simplified form ( cf C/C#), D uses the tag+block (version condition), static-if is for a different purpose
Python isnt really directly comparable ( not compiled, late bound, runtime checks only), Java doesnt have condcompile at all (always false expressions compiler optimised away).
Own-if - also no : C# uses #if,
D static-if is not the same as its own language if ( though confusingly closely resembles it)
- all of them are moving (moved) in various levels away from the C - preprocessor like #if form (syntax, semantic and purpose).
so I'd say the answer to 'who' is 'all of them'.

Do you plan on supporting a true static-if then that has access to constants and type info?

As stated earlier preferably not if its avoidable (not needed).
Leaving aside condCompile ( condCompile done not using an earlier processed static if-then-else ladder form)
what use would cobra make of having that - it doesnt have templates or anything I can see at the moment that would demand it.

I think we can manage quite clearly and satisfactorily without it.

That's like if I said "that car has no steering wheel" and someone said "that's because we didn't put one in'

to continue the analogy "we didnt put one in because we steer by an autonomous sentient equine organism taking us where we want to go'. A steering wheel in this construction is both irrelevant and unnecessary.

it's a special, limited case of "branch-with-attendant-conditions setup"

Thats a conceptual mistake that using an '#if' forms leads you into...
Its not a branch with conditions at all (which is what 'if' usually means and what it looks like),
Its a match/check to a compile-time situation that leads you to include or not a blob of code.
- the only branching is in the decision whether or not to include.

The intention with a declarative tag ( like 'ver'/'version') is to make this 'optionally include a block of code' look like a
'heres an optionally included code block' rather than
'heres a similar looking if condition to a real code branch which it isnt cos it may or may not include/compile the following code'

sometimes want not match.With no "not" and no @else, you could be stuck

right but not having 'not' or @else doesnt preclude having something do the same as 'not match this'

Currently these are here setup as optionally-included blocks on a match, a not-match or @else equivalent should be explicitly presented the same way - an explicitly tagged block (match situation reversed).
The most common situation is an 'allOthers' off of a single clause

I'm trending to something like 'otherThan' or some synonym

@ver.mono 
        a = 50
        # do something mono specific
@ver.otherThan.mono 
        a = 500
        # for all other non mono things do something else

pretty clear, no (human) parsing #if conditions and calculating the 'not condition' for #else

cobra versioning

looks like D overloads versionConditions such that an integer is treated as a versionNumber and tested >=
while an Identifier matches/tests existence to a defined value.
similar is doable here

Code: Select all

@ver.cobra.080-092
  # code  between versions 0.80-0.92
@ver.cobra.092
  # code for >=version 0.92
#or even
@ ver.092


It's also your escape hatch when you need OR, AND or a comparison in your version() ... which does not support such things.

- Its not clear that it cannot support such things (or that it needs to) but if it does it doesnt need to be in the form of an explicit
condition and
- if an escape hatch is needed its not impossible to (cut) one later

@if JVM
    <some code>
# and if we want a one liner, we could entertain:
@if JVM, <some code>

This is awfully similar in appearance to

if JVM
    <some code>
# and 
if JVM, <some code>

as executable cobra code
and (rhetorically) whats with the Caps ? - a holdover from the C/C++ #define form

@ver.jvm
    <some code>
# and  a one liner
@ver.jvm <some code>

more obviously chunks and not a code branch ..

wary of adding a new feature when the last new bug I found was yesterday

So yesterday was a good day - you found out something new you didnt know

Every new use will uncover bugs, every new user will probably do the same if we're lucky - Its good.
Fix them or log them and move on.
Theres no software anywhere thats totally bug clean and has all the features desired and not dead - its the nature of the beast.
Which begs a question - How many days would you have to go without finding a new bug before you would be comfortable with adding a new feature?

We'll need CLR and JVM version numbers.

CLR for modding off available library classes and methods presumably - why JVM/Java versions?
Its touted as library backwards compatible .

You seem allergic to the #if/#define approach found in C# and other languages, but I'm not. You admit it will be needed in some situations. But then if that's case, I don't see the need for @ver and @debug.

Allergic is a bit strong - I do feel we can and must do much better. (meaning and clarity)
I dont believe I have indicated it will be needed in some cases, in fact I believe the opposite but I'm not precluding providing an escape hatch if necessary ( as a very very last resort when all else fails ).

The purposes for which I would use condCompile and the purposes I envisage are more than adequately addressed by tag-and-block
and are presented much more clearly in doing so.

predefined setups

so should add CLR and JVM version testing to whats currently matched against.

I'm wondering what you see people writing (application) cobra code for that needs to condCompile on
embedded-runtime and detailed-stack-trace (?)

@ver is that it doesn't just check for the existence of the symbol, it also has a matching option..

Where do you think @ver is matching options (values?) ?
Its acting as a match to a situation ( that could be looked at as checking existence of a symbol - for -define compiler settings anyway).
@env has some additional checking for matching values but that was just for completeness - it would be sufficient just to
test for existence of the env variable and control builds only via thatnot their values.

SFAICT version number matching is only time @ver needs to concern itself with something approaching values
- the remainder are all situations (or symbols)

(this wiki discussion format is not very well suited to raising and addressing lotsa discussion points - makes for long somewhat disjointed postings)

[hopscc]

static-if in D and 'It's also your escape hatch when you need OR, AND or a comparison in your version() '

I get the impression with D that that is not the case - in static-if the test can only use symbols normally used in an expression
at the same place.
'the symbols referred to in the AssignExpression can be any that can normally be referenced by an expression at that point'.
and
'Version identifiers are in their own unique name space, they do not conflict with debug identifiers or other symbols in the module'.

which I take to mean that the namespaces are separate and inaccessible to each other.

Sorry should have noted yesterday the URL for the D version desc.
http://dlang.org/version.html

[Charles]

Your @ver idea supports comparisons albeit in a previously unseen syntax for Cobra (and actually most other languages I have seen). You also have "otherThan" to fill in for "not". These are evidence that @ver is a half-baked if-statement.

Also, a key characteristic of Cobra is that there is one reasonable way to write various experssions such as "equals". In Cobra that is "==". And it remains "==" whether you use it in an if-statement, assertion, unit test or contract. (Contrasted with C# where things are done differently in different places such as Is.EqualTo() for unit tests.) Same with "not".

This is a key characteristic of Cobra and I will not break it for conditional compilation.

Its not a branch with conditions at all (which is what 'if' usually means and what it looks like),
Its a match/check to a compile-time situation that leads you to include or not a blob of code.
- the only branching is in the decision whether or not to include.

The branching your @ver has includes:
1. is the symbol defined at all
2. is the symbol not defined (otherThan)
3. does the symbol match a string literal

That's branching. Not very powerful branching, but branching nonetheless. You can slap another label on it, but the branching is still there.

Given that Cobra developers must already know if-statments like so:

if foo
    .doSomething
if foo == 'bar'
    .doSomething
if foo <> 'bar'
    .doSomething
else
    .doSomethingElse

# then this is the most clear approach to conditional compilation:
@if FOO
    .doSomething
@if FOO == 'bar'
    ...
@if FOO <> 'bar'
    ...

# the @ver form doesn't reuse any concepts:
@ver.FOO
    ...
@ver.FOO.'bar'
    ...
@ver.otherThan.FOO
    ...

I'm not switching all the syntax up just because it's conditional compilation. You also mentiond code ranges. In code, we check a range with "80 <= x <= 92". The compiler directive isn't going to be something entirely different. In fact, using @if gives us an obvious "go to place" when we need to extend its abilities: do what the if-statement does. Easy.

Re: caps, I'm willing to entertain lower case.

Btw I hate having to specify "mono" twice here:

@ver.mono
    ...
@ver.otherThan.mono
    ...

Why don't you like the D's "else" approach?

@ver.mono
    ...
@else
    ...

Re: bugs, I would like to see 30 days without anyone finding a bug. However, I realize that the JVM work cannot proceed well without conditional compilation, and I'm willing to accept that.

Re: JVM versions, "backwards compatible" does not imply that you don't want to do something additional on a newer platform that cannot be done on an earlier, including using a new class or method in the jvm lib.

Re: embedded-runtime and detailed-stack-trace (dst), iirc I would benefit from at least the detailed-stack-trace in the std lib implementation. Application developers will probably not need these.

Where do you think @ver is matching options (values?) ?

You have given more than one example of matching a value. You wrote:

@ver.env.OSVer.'Windows_NT'
@ver.OSVer.'0.5'
# and others

Those are comparisons. Calling them "declarations" or some other name does not change that fact.

You mention "clear" or "clearer" or "clearly" quite often. But @ver is less clear than @if because it introduces entirely different ways of expressing conditions than the if-statement that Cobra coders will already know. Also, there's nothing unclear about "@if not MONO" so I'm not sure what could be improved. And if it was improved, we'd take it back to the if-statement so it could be more clear as well.

[Charles]

These are my notes for @if:

http://cobra-language.com/trac/cobra/wiki/IfDirective

[hopscc]

It would seem to me that you are caught up on condCompilation using conditions and branches (a la C preprocessor )
and not reading/internalising what I've been trying to present ( obviously pooly).

condCompilation triggers off a match to a situation/setting.
Some of these are predefined, some can be user setup.
as repeatedly noted - this is not a 'condition' in the binary boolean expression sense.

These (predefined at least) situations are described by a tag (which could perhaps be thought of as a symbol - but the symbol is not
the variable ( in a #define sense)).

There is no branch - there is include-block or not include-block

I have otherThan to provide for situations other-than those given - not to 'fill in' for not or anything else.
( though if the view is only through the filter of 'it must be conditions and branches' the effect can appear the same .
Taking that as 'evidence' of something you characterise (multiple times) as 'half-baked' same-as-your-version is at best wilfully intellectually dishonest ).

The branching your @ver has includes:
1. is the symbol defined at all
2. is the symbol not defined (otherThan)
3. does the symbol match a string literal

That's branching....

(underlining mine)

Nice tautology by your definitions - you name it branching because its branching using situations you define as branching conditions therefore its branching.

Its not a 'symbol', its not 'defined' , its not branching
matching situations: - situation described using tags - match to that or to otherThan-that. include or not include block.

re using tag (e.g. mono) twice and not using else

You'll notice that a feature of this is that the condCompile form is not ever in a compound form
Its always only tag-and-block without subordinate clauses or any possibility of if..else like ladders

@ver.mono
    ...
@ver.otherThan.mono
    ...

1) the tags and matches are each stand alone - single tag-test and block for each situation
2) using a subordinate joining token ( 'else') makes a compound statement the pieces of which must be consecutive
( or you have to have conditions and boolean logic which take us back to #define and #if/#else)
3) finally and minorly 'else' takes you back to looking at this in a the manner of a condition-and-branch paradigm
(also and less importantly its easier to implement in this manner - no needs for dangling state info to determine what
the last set of tested tags were)

@ver.mono
    # mono specific...
    ....
... code not conditional ... 

@ver.otherThan.mono
   # specific to other than  mono  
    ...

It looks slightly redundant if you have the two blocks contiguous to each other ( and you're expecting something like if/then/else)

re: examples of matching to a value

env - already noted as probably unnecessary (env) AND that even if not value matching is probably not required
ver.OSVer was a throwaway note on matching to platform (and version string)
superceded to tag and version literal ( where match has a specific meaning to gte version )
or range

@ver.cobra.93
    # code compiled/included  only on cobra version gte 0.9.3
@ver.clr.40
    # code compiled/included only on clr >= 4.0

Pls take a step outside your opinion/fixation of #if/#define, branches and conditions (language constructs) as the one-and-only-true-way and reread everything i've posted on this again.

I made some notes for @ver at
http://cobra-language.com/trac/cobra/wiki/VerDirective

I'll have a followup implementation patch on ticket:312 (support otherThan, version checking and cmdline -define)
once I get the cmdline bit added.

[hopscc]

I've been looking for opinions on D condCompile using versioning and/or reasons why D went that way

Concrete info seems pretty thin on the ground - from the Dlang forum looks like it grew incrementally out of lack of condCompile facilities at all and static-if and static-assert being contorted with to do something (that was mostly unreadable/unintelligible)..

Search dlang forum

Theres a pretty strong indication that WB doesnt think (bool) conditions (in any form) in condCompile is a desirable direction to take

(OTOH maybe I'm reading into this what I want to read into this)

Opinions
http://the-free-meme.blogspot.co.nz/2009/03/d-conditional-compilation.html

http://forum.dlang.org/thread/akef9g$gvt$1@digitaldaemon.com?page=2
(4th entry down - 'Walter' )

http://forum.dlang.org/thread/h5riu6$li3$1@digitalmars.com?page=1

http://forum.dlang.org/thread/gmrocl$1fk7$1@digitalmars.com?page=3
Here we go - design rationale + disagreement (2nd entry down - and very interesting/pertinent discussion rest of thread)

[Charles]

From a couple posts ago:

Every new use will uncover bugs, every new user will probably do the same if we're lucky - Its good.

No, it's not. Every new use of a compiler should not uncover bugs. And actually that's true today. I do not find a bug in Cobra every time I use it. But I find them too often.

Back to @ver:

@ver.otherThan.foo is the opposite of clear and the opposite of your comment that "no (human) parsing" is necessary. The person has to know that "otherThan" is special. It's not like @ver.mono or @ver.jvm.

as repeatedly noted - this is not a 'condition' in the binary boolean expression sense.

I know you believe that, but I think that is factually wrong. Your proposals here include something along the lines of:
@ver.foo
@ver.foo.'compare-with-me'
@ver.otherThan.foo
@ver.something.9
@ver.something.99-110

That's five compile-time conditions. As proof, I bet the implementation in the compiler to make those things work involves if-statements.

There is no branch - there is include-block or not include-block

"include-block or not include-block" is in fact a compile-time branch.

I have otherThan to provide for situations other-than those given - not to 'fill in' for not or anything else.
( though if the view is only through the filter of 'it must be conditions and branches' the effect can appear the same .

If the behavior/semantics between X and Y are the same, then X and Y are the same.

Btw more than just "otherThan" must be covered. There were version ranges and matching a string value, remember?

Taking that as 'evidence' of something you characterise (multiple times) as 'half-baked' same-as-your-version is at best wilfully intellectually dishonest ).

No intellectual dishonesty here on either of our parts. Just a disagreement.

Nice tautology by your definitions - you name it branching because its branching using situations you define as branching conditions therefore its branching.

I'm not the source of what branching is. It's a well understood concept in computing.

For example, branching requires a condition. Interestingly, at http://dlang.org/version.html the page is titled "Conditional Compilation" and includes D's version() as one of the ways to do this.

You'll notice that a feature of this is that the condCompile form is not ever in a compound form
Its always only tag-and-block without subordinate clauses or any possibility of if..else like ladders

So the user simulates the "else" part with "@ver.otherThan.mono". (I wonder what happens if I enter "@ver.otherThan" by itself.)

And would you let them simulate an OR like they do in D?

Pls take a step outside your opinion/fixation of #if/#define, branches and conditions (language constructs) as the one-and-only-true-way and reread everything i've posted on this again.

I did reread your posts. I did not change my mind.

Also, I would ask that you step outside your opinion that @if would somehow be confusing (it's not) or that it requires "(human) parsing" that somehow @ver does not.

Re: the D discussions, I presume none of them cover the odd form "@ver.otherThan..." or a version directive that has no 'else' since those only apply to your proposed @ver for Cobra.

Also, it's notable that when version() doesn't do what's needed, D programmers cook up some funky code seen at the top of http://forum.dlang.org/thread/gmrocl$1f ... com?page=3 and in Walter's post (more on that below). In Cobra we don't have "template" and "static if" so even if I thought that didn't look like shite, it wouldn't be an option.

Regarding Walter Bright's complaint about the degeneration of #if, by that same logic we should not allow programmers an if-statement in their code...because their programs degenerate into "an utter rat's nest of nested, incomprehensible complexity". Over half the code bases I have looked at are rat's nests indeed. Whether they used #if or not. I wouldn't refrain from having a feature because it may be abused. Everything gets abused eventually.

Anyway, having read Walter's posts, I understand his motivations better than before. Still don't agree and notably others do not as well. His example of how to work around the lack of 'OR' was just silly. If people are going to do an 'OR' then give them one directly. In fact, his OR workaround is the real example of something requiring extra human parsing to figure out what the intent is.

[hopscc]

The person has to know that "otherThan" is special. It's not like @ver.mono or @ver.jvm

Presumably you mean it doesnt relate immediately to a compile-situation symbol (as does 'mono' or 'jvm' or 'debug')
possibly so. OTOH its not a great leap (presuming understanding of 'other than' ), fits exactly with the tag + code-block concept
and isno more difficult (and possibly less difficult ) to grasp than a fully figured binary logic clause
AND more specifically is harder to abuse into a rats nest of unintelligible platform tests.

Your proposals here include something along the lines of:
@ver.foo
@ver.foo.'compare-with-me'
@ver.otherThan.foo
@ver.something.9
@ver.something.99-110

close.
its
@ver.foo[.optionally-more-specific-foo-description]
and its inversion
@ver.otherThan.foo[.optionally-more-specific-foo-description]
The numbers and ranges are to match versions which you seem to think is necessary.
The string match was for env which I've mentioned is probably unnecessary...

As proof, I bet the implementation in the compiler to make those things work involves if-statements

The run sub-command of the compiler uses if-statements as well - does that make it a condition?
The implementation of anything non trivial in computer languages involves if-statements (or equivs) - so?
chk it out ( 2nd patch ticket:312 - CobraParser .atIdStmt and .condCompile )

"include-block or not include-block" is in fact a compile-time branch.

Branch to what?
Its compile-time code inclusion/exclusion.
It can(has) been implemented as a compile time branch check (#if) but thats confusing the implementation with the goal.

for example branching requires a condition

Which does not make everything that has a condition ( or what you characterise as a condition) a branch and therefore demanding an if-statement.

so the user simulates the "else" part with "@ver.otherThan.mono". (I wonder what happens if I enter "@ver.otherThan" by itself.)

Not exactly - they can do the equivalent of an else as a separate ( stand alone) explicitly tagged tag+code Block using '@ver.otherThan'.
Its always specified by itself ( these are all unrelated/unattached non subordinate clauses).

And would you let them simulate an OR like they do in D?

Probably not - I'm trending to the direction that its likely to be clearer to duplicate the code block (or make a call to a method) for the additional match than to open a possible intelligibility gap by allowing compounded situation checks
- also as an incentive to 'dont do that'.
( but I also havent done alot/any cobra code that had any requirement for an OR)

@if would somehow be confusing (it's not) or that it requires "(human) parsing" that somehow @ver does not.

I think its clear that #if(def)/@if and its ilk has trended to be confusing (or made confusing) hence its increasing deprecation/constraining of capability.
While @ver may not be totally non-confusing I think it is clear that it should be at least less so and less likely to be made/used so
( if only because its more limited by design/intention).
The difference is in degree not necessarily kind.

"Re: the D discussions, I presume none of them cover the odd form "@ver.otherThan..." or a version directive that has no 'else' since those only apply to your proposed @ver for Cobra."

Correct - I dont support the idea of an 'else' or any other subordinately/compound clause condCompile structure because I think they lend themself to making what is or is-not included more obscure than a direct tag + include block especially if the conditions are allowed to become more complicated (compounded).
Comparatively its the difference between (human) parsing a (possibly complex boolean) condition, working out if its applicable then determining which/whether there is a corresponding code block that applies
vs matching a (hopefully) small set of situations and including (or not) the associated code block.

"when version() doesn't do what's needed, ... don't have "template" and "static if"..
right so its a strong indication that ( we/I think) you 'shouldnt do that'...
( Note that its not impossible just that these setups make it difficult to do so)...

Regarding Walter Bright's complaint about the degeneration of #if, by that same logic we should not allow programmers an if-statement in their code...because their programs degenerate into "an utter rat's nest of nested, incomprehensible complexity". Over half the code bases I have looked are rat's nests indeed. Whether they used #if or not. I wouldn't refrain from having a feature because it may be abused. Everything gets abused eventually.

Excellent points but

• (language) if-statements are unfortunately necessary ( for the language we have anyway) and there is some addressing of that by providing the branch alternative ( for clarifying if-else ladders).
  
• I would submit that its easier and more likely for someone to make bigger rattier rats nests with both fully featured #if and if-statements than with if-statements alone.
  
• If you think portions of a feature may be abused (and history shows that it does/has been - to incomprehensibility) that doesnt preclude redesigning/changing/constraining to limit (known) possibilities for abuse rather than just regurgitating the same-old-thing for familiarities sake.

"Still don't agree and notably others do not as well."
conversely others do.
I was struck ( or perhaps sensitised) to the comments that mentioned version() as a advantageous feature over C/C++ #if/Ifdef

"His example of how to work around the lack of 'OR' was just silly.
If people are going to do an 'OR' then give them one directly"
(or make it difficult/impossible for them to do so).