Code in version blocks must be syntactically correct even if the condition is not met and the code isn't compiled - ie, the compiler still parses the code. But this makes writing libraries that compile with both D1 and D2 difficult - I want to add features for D2 users without having to distribute a separate version of the library.

version(D_Version2) {
  struct SomeStruct {

    // D2 copy ctor
    this(this) {}

  }
}

D1 chokes on that, which is expected behaviour according to the spec. But how do I get the same behaviour as #if and #else - ie, tell the compiler to completely ignore anything if some condition is not met?

John C wrote:
> Code in version blocks must be syntactically correct even if the condition is not met and the code isn't compiled - ie, the compiler still parses the code. But this makes writing libraries that compile with both D1 and D2 difficult - I want to add features for D2 users without having to distribute a separate version of the library.
> 
> version(D_Version2) {
>   struct SomeStruct {
> 
>     // D2 copy ctor
>     this(this) {}
> 
>   }
> }
> 
> D1 chokes on that, which is expected behaviour according to the spec. But how do I get the same behaviour as #if and #else - ie, tell the compiler to completely ignore anything if some condition is not met?

String mixin.  Not pretty, but it works.

--bb

On Sun, 09 Mar 2008 11:22:29 +0000, John C wrote:

> Code in version blocks must be syntactically correct even if the condition is not met and the code isn't compiled - ie, the compiler still parses the code. But this makes writing libraries that compile with both D1 and D2 difficult - I want to add features for D2 users without having to distribute a separate version of the library.
> 
> version(D_Version2) {
>    struct SomeStruct {
> 
>      // D2 copy ctor
>      this(this) {}
> 
>    }
> }
> 
> D1 chokes on that, which is expected behaviour according to the spec. But how do I get the same behaviour as #if and #else - ie, tell the compiler to completely ignore anything if some condition is not met?

You need to use string mixins.

For example ...

 version(D_Version2) {
    mixin(
    `struct SomeStruct {`
      // D2 copy ctor
    `  this(this) {}`
    `}`
    );
 }

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Bill Baxter wrote:
> John C wrote:
>> Code in version blocks must be syntactically correct even if the condition is not met and the code isn't compiled - ie, the compiler still parses the code. But this makes writing libraries that compile with both D1 and D2 difficult - I want to add features for D2 users without having to distribute a separate version of the library.
>>
>> version(D_Version2) {
>>   struct SomeStruct {
>>
>>     // D2 copy ctor
>>     this(this) {}
>>
>>   }
>> }
>>
>> D1 chokes on that, which is expected behaviour according to the spec. But how do I get the same behaviour as #if and #else - ie, tell the compiler to completely ignore anything if some condition is not met?
> 
> String mixin.  Not pretty, but it works.
> 
> --bb

Feared as much.

I'm wondering what the point is in having a version block's syntax checked when the code it contains isn't compiled.

On Sun, 09 Mar 2008 14:50:03 +0100, John C <johnch_atms@hotmail.com> wrote:

> Bill Baxter wrote:
>> John C wrote:
>>> Code in version blocks must be syntactically correct even if the condition is not met and the code isn't compiled - ie, the compiler still parses the code. But this makes writing libraries that compile with both D1 and D2 difficult - I want to add features for D2 users without having to distribute a separate version of the library.
>>>
>>> version(D_Version2) {
>>>   struct SomeStruct {
>>>
>>>     // D2 copy ctor
>>>     this(this) {}
>>>
>>>   }
>>> }
>>>
>>> D1 chokes on that, which is expected behaviour according to the spec. But how do I get the same behaviour as #if and #else - ie, tell the compiler to completely ignore anything if some condition is not met?
>>  String mixin.  Not pretty, but it works.
>>  --bb
>
> Feared as much.
>
> I'm wondering what the point is in having a version block's syntax checked when the code it contains isn't compiled.

Simple answer to that is it might get compiled some other time, and whoever uses your code at that time would probably not enjoy being bitten by such errors.
Say you change some version'd part of your code, and forget to check it for bugs (you've compiled it, it works, life's great, but you forgot that small version=foo flag).

-- Simen

Simen Kjaeraas wrote:
> Simple answer to that is it might get compiled some other time, and whoever uses your code at that time would probably not enjoy being bitten by such errors.
> Say you change some version'd part of your code, and forget to check it for bugs (you've compiled it, it works, life's great, but you forgot that small version=foo flag).
> 
> -- Simen

Continuous integration is great. I should see what's required to get CruiseControl working and happy with D. It should be relatively easy if you use DSSS, except if you have multiple targets or platforms. Multiple targets is doable, but requires parsing the dsss.conf file. Multiple platforms is doable, but you'd have to arrange for separate dmd/gcc installations and enumerate them somewhere. Maybe separate DSSS installations, since you can't (as far as I could tell after about five minutes of searching) specify which rebuild profile to use on the command line.

John C wrote:
> I'm wondering what the point is in having a version block's syntax checked when the code it contains isn't compiled.

Unambiguous parsing. One of the main goals of the D language AFAIK is to make  the syntactic analysis independent of the semantic analysis (one of the things that makes C++ so hard to compile). Thus, the syntax tree for the code must be able to built without knowing which version identifiers are active.

Christopher Wright wrote:
> I should see what's required to get
> CruiseControl working and happy with D.

That would be much appreciated, I find CruiseControl very useful!