Porting D2 code to D1

[Leandro Lucarella]

Bill Baxter, el 18 de julio a las 17:50 me escribiste:
> >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.

That's true, but I think this opens a new posibility to D to introduce new
small backward incompatible features in a stable version giving the user
some time to update (or keep the old behavior), like Python's __future__
module[1].

That would make D evolving much easier...

[1] http://www.python.org/dev/peps/pep-0236/

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
SATANAS EN COMISARIA
	-- Crónica TV