I was looking through the versioning examples on the specification.   I don't see any examples of an expression.

IE:
version( API > 4 )
{
    ... Something supported in great than version 4 of the API
} else version ( API > 2 ) {
    ... Something supported in great than version 2 of the API
} else {
   ... Some code that only works on really old API versions..
}

Is this supported?  And can imports declare version identifiers?

Sha Chancellor wrote:
> I was looking through the versioning examples on the specification.   I don't see any examples of an expression.
> 
> IE:  version( API > 4 ) {
>     ... Something supported in great than version 4 of the API
> } else version ( API > 2 ) {
>     ... Something supported in great than version 2 of the API
> } else {
>    ... Some code that only works on really old API versions..
> }
> 
> Is this supported?  And can imports declare version identifiers?

Unfortunately, comparison operators don't work with version (at least they didn't last time I tried it). For now, we'd have to do messy stuff like this...

version(API_1) version = API_Not_Supported;
version(API_2) version = API_Not_Supported;
version(API_3) version = API_Not_Supported;

version(API_4) version = API_Supported;
version(API_5) version = API_Supported;
version(API_6) version = API_Supported;

version(API_Not_Supported)
{
    static assert(0);
}
version(API_Supported)
{
    // ...
}


As to your other question, I think imports can declare version identifiers with the "version = Whatever;"  syntax, but I don't think I've ever tried it.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Maybe we could talk walter into it.. =/  I _really_ don't like the method you proposed.  No offence, it just looks kludgy. It makes you repeat code for versions which may have compatible code:

IE:

version( API_2 ) {
CODE
} else version( API_3 ) {
SAME code
} else
{
SOME CODE FOR OLD VERSION, which would still get processed on API_4, not just
API_1, which is definately not desired.
}

Walter?  Comments?


In article <cds3cd$2pva$1@digitaldaemon.com>, J C Calvarese says...
>
>Sha Chancellor wrote:
>> I was looking through the versioning examples on the specification.   I don't see any examples of an expression.
>> 
>> IE:
>> version( API > 4 )
>> {
>>     ... Something supported in great than version 4 of the API
>> } else version ( API > 2 ) {
>>     ... Something supported in great than version 2 of the API
>> } else {
>>    ... Some code that only works on really old API versions..
>> }
>> 
>> Is this supported?  And can imports declare version identifiers?
>
>Unfortunately, comparison operators don't work with version (at least they didn't last time I tried it). For now, we'd have to do messy stuff like this...
>
>version(API_1) version = API_Not_Supported;
>version(API_2) version = API_Not_Supported;
>version(API_3) version = API_Not_Supported;
>
>version(API_4) version = API_Supported;
>version(API_5) version = API_Supported;
>version(API_6) version = API_Supported;
>
>version(API_Not_Supported)
>{
>     static assert(0);
>}
>version(API_Supported)
>{
>     // ...
>}
>
>
>As to your other question, I think imports can declare version identifiers with the "version = Whatever;"  syntax, but I don't think I've ever tried it.
>
>-- 
>Justin (a/k/a jcc7)
>http://jcc_7.tripod.com/d/

Sha Chancellor wrote:
> Maybe we could talk walter into it.. =/  I _really_ don't like the method you
> proposed.  No offence, it just looks kludgy. It makes you repeat code for
> versions which may have compatible code: 

Yep. It's a definitely a kludge.

I complained about the lack comparison operators in version a long time ago. I think Walter replied to it, but it was more "maybe someday" than "oh, I'll get right on that." I don't recall anyone bringing up this issue recently. I've become resigned to the reality that we'll probably have to make it work the way it is. Kludgy, yes. Impossible, I don't think so.

Maybe D 2.0 will have some cool new versioning facilities.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

In article <cdsae0$2vtc$1@digitaldaemon.com>, J C Calvarese says...
>
>Sha Chancellor wrote:
>> Maybe we could talk walter into it.. =/  I _really_ don't like the method you proposed.  No offence, it just looks kludgy. It makes you repeat code for versions which may have compatible code:
>
>Yep. It's a definitely a kludge.
>
>I complained about the lack comparison operators in version a long time ago. I think Walter replied to it, but it was more "maybe someday" than "oh, I'll get right on that." I don't recall anyone bringing up this issue recently. I've become resigned to the reality that we'll probably have to make it work the way it is. Kludgy, yes. Impossible, I don't think so.
>
>Maybe D 2.0 will have some cool new versioning facilities.


I would think that this is a rather important feature.  Maybe we should tie walter up and force him to code :)  Does he add features if we donate funds toward it?

Sha Chancellor wrote:
> In article <cdsae0$2vtc$1@digitaldaemon.com>, J C Calvarese says...
> 
>>Sha Chancellor wrote:
>>
>>>Maybe we could talk walter into it.. =/  I _really_ don't like the method you
>>>proposed.  No offence, it just looks kludgy. It makes you repeat code for
>>>versions which may have compatible code: 
>>
>>Yep. It's a definitely a kludge.
>>
>>I complained about the lack comparison operators in version a long time ago. I think Walter replied to it, but it was more "maybe someday" than 

Perhaps the "maybe someday"-ish response was in my head. I think I found the old thread that I was remembering. Here's where is starts:
http://www.digitalmars.com/drn-bin/wwwnews?D/18144

I just now looked at the old thread. It seemed to be a Walter-vs-everyone else thread where most posters complained that version isn't as flexible as #define.

(My old post is in there somewhere, but it's neither the most important post in the thread nor as cool as I remember it.)

>>"oh, I'll get right on that." I don't recall anyone bringing up this issue recently. I've become resigned to the reality that we'll probably have to make it work the way it is. Kludgy, yes. Impossible, I don't think so.
>>
>>Maybe D 2.0 will have some cool new versioning facilities.
> 
> 
> 
> I would think that this is a rather important feature.  Maybe we should tie
> walter up and force him to code :)  Does he add features if we donate funds
> toward it? 

LOL.

I don't think Walter can be bought. I think he enjoys working for himself too much.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Sha Chancellor wrote:
> I was looking through the versioning examples on the specification.   I don't see any examples of an expression.
> 
> IE:  version( API > 4 ) {
>     ... Something supported in great than version 4 of the API
> } else version ( API > 2 ) {
>     ... Something supported in great than version 2 of the API
> } else {
>    ... Some code that only works on really old API versions..
> }
> 
> Is this supported?  And can imports declare version identifiers?

It is supported through the back door.

version = 4; or -version=4 on the commandline will do

version (3) {
  // left out
}

version (4) {
  // compiled
}

version (5) {
  // compiled
}

There is also the possibility for an else clause:

version (4) {
  // compiled
}
else {
  // left out
}

The docs say:

-version=level
  compile in version code >= level

Note that for
-debug=level
  compile in debug code <= level


Lars Ivar Igesund

In article <cdt152$ip1$1@digitaldaemon.com>,
 Lars Ivar Igesund <larsivar@igesund.net> wrote:

> It is supported through the back door.
> 
> version = 4; or -version=4 on the commandline will do
> 
> version (3) {
>    // left out
> }
> 
> version (4) {
>    // compiled
> }
> 
> version (5) {
>    // compiled
> }
> 
> There is also the possibility for an else clause:
> 
> version (4) {
>    // compiled
> }
> else {
>    // left out
> }
> 
> The docs say:
> 
> -version=level
>    compile in version code >= level
> 
> Note that for
> -debug=level
>    compile in debug code <= level
> 
> 
> Lars Ivar Igesund


This doesn't fix the problem I described.   For example:  In MacOS 9 and below there are different versions of the API as declared in defines. For some cross-version compilation you need #if API_VERSION < 3 #endif crap going on.   But there is different version numbers for different APIs.   While this might work if i only ever used one module.   It doesn't fix the problem.


It's also flawed in another way:  Maybe version(4) {} and version (5) {} code are mutually exclusive but you want to compile version 4?  How is that accomplished.

Sha Chancellor wrote:


>>The docs say:
>>
>>-version=level
>>   compile in version code >= level
>>
>>Note that for
>>-debug=level
>>   compile in debug code <= level
>>
>>
>>Lars Ivar Igesund
> 
> 
> 
> This doesn't fix the problem I described.   For example:  In MacOS 9 and below there are different versions of the API as declared in defines.   For some cross-version compilation you need #if API_VERSION < 3 #endif crap going on.   But there is different version numbers for different APIs.   While this might work if i only ever used one module.   It doesn't fix the problem.
> 
> 
> It's also flawed in another way:  Maybe version(4) {} and version (5) {} code are mutually exclusive but you want to compile version 4?  How is that accomplished.

Well, note that I switched debug and version above :). This means that specifying version=4 will compile in version 4. Version=5 will compile in both (as is logical).

Alas, AFAICS, only one version integer can be used in one compilation. Thus you probably need to use string identifiers and nested version statments for the more complex stuff, but this might not be enough either, at least not without doubling up the code. The best (and just a little bit more complex) solution would probably be to be able to specify integers like this (or similar)

-version[ONE_API]=4 -version[OTHER_API]=7

and then have expressions that can use ONE_API and OTHER_API like you sketched in your first post.

Lars Ivar Igesund