Porting D2 code to D1

[Yigal Chripun]

Ryan Bloomfield wrote:
> Bill Baxter Wrote:
> 
>> 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
> 
> "pragma" won't allow a new keyword.  What if someone comes up with an
> experimental feature, that later proves useful enough to become part
> of a standard.  In C and C++, this happens all the time.  C
> exceptions are a good example.

IMHO, vendor extensions are the wrong way to add features to the
language. This promotes vendor lock-in or pollutes the code with lots of
 code like:

if compiler vendor is X
    do A
else if ...
..
else
   do Z

anyway, a much better way is to allow extensibility without the need to
write a whole compiler, via a plug-in mechanism. This also allows for
non compiler experts to add features that do not actually require
oneself to be a compiler expert. extensions for Firefox, and plug ins
for eclipse are good examples of such a mechanism that brought a lot of
innovation and new features. also the best of those addons can be added
to the main software itself, as done in Firefox (only where it makes
sense, of course)
there are other languages that already provide this.
to implement it you'd need a way to interface with the compiler via an
API and use AST macros (currently planned for D v3) or something similar
to define the new features.

This will allow you to provide language extensions as libraries instead
of requiring a specific compiler.