Porting D2 code to D1

[Jason House]

Jarrett Billingsley Wrote:

> "Jason House" <jason.james.house at gmail.com> wrote in message 
> news:g5ld20$1jbt$1 at digitalmars.com...
> > It may sound backwards, but I think it may be the best way to get things 
> > like Tango to move forward to D2.
> >
> > Tango officially supports D1.  If it were to add D2 support, someone would 
> > have to port the D1 code to D2.  Then, with each change, a similar change 
> > must occur to the D2 code base.  From a maintenance standpoint, this 
> > really shouldn't be acceptable.
> >
> > Since adding concepts such as const to D1 code in an automated fashion is 
> > essentially impossible, it seems the best approach is to convert D2 code 
> > into D1 code.  Programatically, it should be pretty easy to remove 
> > const-awareness.  That'd allow Tango to convert to D2 once and then (more 
> > or less) maintain one code base.
> >
> > Maybe this would require a few special cases with D1-specific and 
> > D2-specific code, but I'd hope that wouldn't be very common.  I guess I 
> > have a few questions:
> >
> > 1. Besides const removal, what else must get done to convert D2 code to D1 
> > code?

I was implicitly assuming something like a port of D1 code to D2 and then back to D2.  Obviously, D2 has cool functionality that would be tough to port to D1.  I probably should have also asked which subset of D2 can be easily converted to D1.  Postblits and such are obviously not portable to D1.


> Just removing const might not work if i.e. you have two methods that do the 
> same thing, but one's const and one's non-const, though the converter might 
> be able to pick those out.

Yeah, given a conflict, it's probably correct to go with the non-const version.



> Code that depends on D2's closure support would not work in D1, and you 
> would have to do semantic analysis to know how to automatically convert from 
> a D2 closure to a D1 struct.

In the clarified context, I think this is an ignorable difference.  



> Some minor syntactic differences, like "invariant {}" in D1 vs. "invariant() 
> {}" in D2, as well as syntactic differences, like the new string literals in 
> D2.
>
> Numerical foreach, but that can be replaced by a simple for loop.
> 
> The (laughable) "enum" syntax for constants.

Those should be easy to convert over.


 
> Struct postblits and dtors (and eventually ctors).
> 
> Stuff that depends on D2's overload sets would be very tricky to convert.
> 
> __traits just cannot be converted for most cases.
> 
> D2 allows you to overload opStar and opDot; both could simply be called 
> manually as methods in the D1 code but you'd need semantic analysis to know 
> when to.


Those are probably all tougher to convert over, but are hopefully out of context.  I'm sure a previous D1 library maintainer wouldn't mind sticking with D1-like syntax :)



> > 2. How can D version-specific code be mixed into a single code base?
> 
> You almost answered it: mixins.  String mixins, that is.
> It's times like this when you kind of wish for a "stupid" preprocessor.

I can't imagine any library maintainer being willing to do that just for portability between D versions.  It'd be nice if D2 code could have something like version(d1){} and version(d2){} for this purpose.  That'd then allow the d2 compiler to ignore version(d1){} and allow the converter to strip out version(d2){}