The version() { ... } blocks would greatly improve from support of boolean operators, which would make code much more readable.

Let us assume, for example, that I have several version identifiers (VERSION1, VERSION2, VERSION3, VERSION4, etc.) and that a block of code may be compiled in the cases of VERSION1 or VERSION3. It would prove the simplest if one could simply use boolean operators to express combinations of valid versions and thus be able to do


version(VERSION1 || VERSION3)
{
 // ...
}

On Mon, 18 Oct 2010 19:15:47 +0300, F. Almeida <francisco.m.almeida@gmail.com> wrote:

> The version() { ... } blocks would greatly improve from support of
> boolean operators, which would make code much more readable.
>
> Let us assume, for example, that I have several version identifiers
> (VERSION1, VERSION2, VERSION3, VERSION4, etc.) and that a block of
> code may be compiled in the cases of VERSION1 or VERSION3. It would
> prove the simplest if one could simply use boolean operators to
> express combinations of valid versions and thus be able to do
>
>
> version(VERSION1 || VERSION3)
> {
>  // ...
> }

I remember reading somewhere that this limitation is deliberate.

I believe the reason for this is that programmers with a C background will tend to abuse this feature to create near-unreadable code (#ifdef mess).

The solution (workaround) for this, is to create new versions for specific features you wish to enable/disable. For example:

version(Demo) {} else version(Lite) {} else { version = EnableFeatureX; }
version(EnableFeatureX) { ... }

One thing people seem to agree with is that version statements could use the negation (!) operator. Then the above could be written as:

version(!Demo) version(!Lite) { version = EnableFeatureX; }

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On Mon, 18 Oct 2010 12:15:47 -0400, F. Almeida <francisco.m.almeida@gmail.com> wrote:

> The version() { ... } blocks would greatly improve from support of
> boolean operators, which would make code much more readable.
>
> Let us assume, for example, that I have several version identifiers
> (VERSION1, VERSION2, VERSION3, VERSION4, etc.) and that a block of
> code may be compiled in the cases of VERSION1 or VERSION3. It would
> prove the simplest if one could simply use boolean operators to
> express combinations of valid versions and thus be able to do
>
>
> version(VERSION1 || VERSION3)
> {
>  // ...
> }

This has been discussed heavily in the past.  Walter doesn't want to do it, and this is one of those "Walter knows best" deals, don't bother trying.

-Steve

Vladimir Panteleev wrote:
> On Mon, 18 Oct 2010 19:15:47 +0300, F. Almeida <francisco.m.almeida@gmail.com> wrote:
> 
>> The version() { ... } blocks would greatly improve from support of
>> boolean operators, which would make code much more readable.
>>
>> Let us assume, for example, that I have several version identifiers
>> (VERSION1, VERSION2, VERSION3, VERSION4, etc.) and that a block of
>> code may be compiled in the cases of VERSION1 or VERSION3. It would
>> prove the simplest if one could simply use boolean operators to
>> express combinations of valid versions and thus be able to do
>>
>>
>> version(VERSION1 || VERSION3)
>> {
>>  // ...
>> }
> 
> I remember reading somewhere that this limitation is deliberate.
> 
> I believe the reason for this is that programmers with a C background will tend to abuse this feature to create near-unreadable code (#ifdef mess).

Yes. Unfortunately the current situation doesn't really prevent that.

My opinion (a significant departure from the current situation, unfortunately):
It should be possible to define version identifiers with booleans.

version EnableFeatureX = !Lite && !Demo;
Possibly:
* make it illegal to define a version identifier from inside a version {} block.
* disallow duplicate version definitions.
* require declarations for all version identifiers. Versions which are set from the command line should be explicitly declared, eg:
version Lite = extern;
version Demo = extern;

That would make creating a bird's nest impossible.
And currently, you can make a typo like:
version(Linix) {}
and it compiles happily. I don't like that. Especially when we have builtin names like D_Inline_Asm_X86_64!

Dnia 18-10-2010 o 18:15:47 F. Almeida <francisco.m.almeida@gmail.com> napisał(a):

> The version() { ... } blocks would greatly improve from support of
> boolean operators, which would make code much more readable.
>
> Let us assume, for example, that I have several version identifiers
> (VERSION1, VERSION2, VERSION3, VERSION4, etc.) and that a block of
> code may be compiled in the cases of VERSION1 or VERSION3. It would
> prove the simplest if one could simply use boolean operators to
> express combinations of valid versions and thus be able to do
>
>
> version(VERSION1 || VERSION3)
> {
>  // ...
> }

You can have it now:

template isVersion(string ver) {
    enum bool isVersion = !is(typeof({
          mixin("version(" ~ ver ~") static assert(0);");
    }));
}

static if (isVersion"VERSION1" || isVersion!"VERSION3") {
    ...
}

If you're rushing to reply "That's hideous!", don't bother. I know.

--
Tomek

Don <nospam@nospam.com> wrote:

> My opinion (a significant departure from the current situation, unfortunately):
> It should be possible to define version identifiers with booleans.
>
> version EnableFeatureX = !Lite && !Demo;

This looks nice to me, except that the rhs looks like normal code. It
gives me the feeling that version foo = sqrt(bar) should work.

Perhaps version foo = version( bar && !baz ); is better. I'm not sure.


> Possibly:
> * make it illegal to define a version identifier from inside a version {} block.

This would break existing code, and it feels logical to write code like
this:

version( foo ) {
    // quite a few lines of dependent code
    version = bar;
}

Of course, the result is cleaner:

version( foo ) {
    // quite a few lines of dependent code
}
version bar = foo;

So I'm a bit torn. Wait, getting a brain wave again....

Ahh. Make that a ++votes.


> * disallow duplicate version definitions.

Absolutely.


> * require declarations for all version identifiers. Versions which are set from the command line should be explicitly declared, eg:
> version Lite = extern;
> version Demo = extern;
>
> That would make creating a bird's nest impossible.
> And currently, you can make a typo like:
> version(Linix) {}
> and it compiles happily. I don't like that. Especially when we have builtin names like D_Inline_Asm_X86_64!

This is an awesome idea. ++votes


-- 
Simen

On Mon, 18 Oct 2010 21:42:20 +0200, Tomek Sowiński wrote:

> Dnia 18-10-2010 o 18:15:47 F. Almeida <francisco.m.almeida@gmail.com>
> napisał(a):
> 
>> The version() { ... } blocks would greatly improve from support of boolean operators, which would make code much more readable.
>>
>> Let us assume, for example, that I have several version identifiers (VERSION1, VERSION2, VERSION3, VERSION4, etc.) and that a block of code may be compiled in the cases of VERSION1 or VERSION3. It would prove the simplest if one could simply use boolean operators to express combinations of valid versions and thus be able to do
>>
>>
>> version(VERSION1 || VERSION3)
>> {
>>  // ...
>> }
> 
> You can have it now:
> 
> template isVersion(string ver) {
>      enum bool isVersion = !is(typeof({
>            mixin("version(" ~ ver ~") static assert(0);");
>      }));
> }
> 
> static if (isVersion"VERSION1" || isVersion!"VERSION3") {
>      ...
> }
> 
> If you're rushing to reply "That's hideous!", don't bother. I know.

Actually, I think it's pretty cool. :)

-Lars

Dnia 18-10-2010 o 22:39:32 Lars T. Kyllingstad <public@kyllingen.nospamnet> napisał(a):

>>> version(VERSION1 || VERSION3)
>>> {
>>>  // ...
>>> }
>>
>> You can have it now:
>>
>> template isVersion(string ver) {
>>      enum bool isVersion = !is(typeof({
>>            mixin("version(" ~ ver ~") static assert(0);");
>>      }));
>> }
>>
>> static if (isVersion"VERSION1" || isVersion!"VERSION3") {
>>      ...
>> }
>>
>> If you're rushing to reply "That's hideous!", don't bother. I know.
> Actually, I think it's pretty cool.

Heh, thanks. Maybe with more templates it won't poke the eye:

static if (anySatisfy!(isVersion, "VERSION1", "VERSION2", "VERSION3", ...))

Still, it is a hack around a language's restriction. But what would be programming without one! :)

-- 
Tomek

On 10/18/10 9:56 PM, Simen kjaeraas wrote:
>> * require declarations for all version identifiers. Versions which are
>> set from the command line should be explicitly declared, eg:
>> version Lite = extern;
>> version Demo = extern;
>>
>> That would make creating a bird's nest impossible.
>> And currently, you can make a typo like:
>> version(Linix) {}
>> and it compiles happily. I don't like that. Especially when we have
>> builtin names like D_Inline_Asm_X86_64!
>
> This is an awesome idea. ++votes

+1 from me too, this could be one of the key parts of a long outstanding version() overhaul.

What also bugs me about the current situation (despite the fact that I think numeric versions should be removed, but that's another story) is that the equals sign to define a new version seems very illogical – »version ~= someUserDefinedVersion« would make much more sense to me…

On 10/18/2010 13:42, Tomek Sowiński wrote:
> template isVersion(string ver) {
>     enum bool isVersion = !is(typeof({
>           mixin("version(" ~ ver ~") static assert(0);");
>     }));
> }
> 
> static if (isVersion"VERSION1" || isVersion!"VERSION3") {
>     ...
> }
> 
> If you're rushing to reply "That's hideous!", don't bother. I know.

Hideous?  That's beautiful!  It lets me pretend that the ugly, restrictive, pointless "version" construct in the language didn't exist, while still reaping the benefits of the version construct.  If I ever write a style guide for D, it will forbid the direct use of 'version' and require that 'isVersion' be used instead.


-- 
Rainer Deyke - rainerd@eldwood.com