Why version() ?

[Walter Bright]

Jarrett Billingsley wrote:
> version(TurnOffSomeFeature) {} else
> {
>     codeForFeature();
> }
> 
> Sometimes you want to have things that turn _off_ code from a default
> of being on.
> 
> I know, I know, Walter said that "[v]ersions should be positive
> things, because a version is something that is being build - one
> doesn't craft a makefile to build a notLinux."  But the fact is,
> platform-specific stuff and code options are two very different use
> cases.  Platform-specific things are completely invisible to the user
> of a library and only one configuration can ever be in use on a single
> platform.  Code options, on the other hand, are based on user
> preference.  Some things are extra, and it makes sense to have
> switches to turn them on.  But some things are the other way, where
> you want them *on* by default and want to have the option of turning
> them *off*.

Even if a feature is on by default, versions should still be a positive 
thing, otherwise you have a double negative:

version (!TurnOffSomeFeature)

Even in regular code, I try to avoid naming things that way, because 
double negatives are twice as hard to comprehend when things get 
complicated. I've gone through my code to remove such double negatives 
as much as possible.

So I suggest:

version (SomeFeature)
{
     codeForFeature();
}

is clearer, even if SomeFeature is the default.