Porting D2 code to D1

[Bill Baxter]

Ryan Bloomfield wrote:
> Bill Baxter Wrote:
>> I think I get your gist.  The syntactic validity requirement is not so 
>> much for catching programming errors as it is for keeping parsing simple 
>> for tools.  That makes sense, and I think I've actually heard that 
>> argument before but just forgot about it.
>>
>> I don't like special cases in general, but maybe an exception can be 
>> made here.  Version blocks that specify a version of the D language 
>> would be treated specially.  That is, the D 1 and 2 specs could be 
>> amended to say that any version matching the pattern "D_Version[0-9]+" 
>> is special, and the contents of the following block should be ignored by 
>> a compiler or tool that does not support that version of the language.
>>
>> --bb
> 
> That would solve the portability issue with D version standards.  What if a standards compliant compiler adds an additional feature that is syntactically incompatible?  Would a special type of version statement be more useful?  As an example 'dversion(__GNUD__) { ... }', or maybe 'version(D_VERSION,__GNUD__){ ... }'.  
> 
> This could even be used to conditionally compile specifically by feature:
> 
> version(D_VERSION,__forany__)
> {
>     forany(...)
>         ...
> }
> else
> {
>     foreach(...)
>         ...
> }
> 
> just my 2 cents


I think preventing the proliferation of vendor-specific language 
extensions is considered a feature of the current system.  There is 
always "pragma" for non-language extensions.

--bb