Porting D2 code to D1

[Jarrett Billingsley]

"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?

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.

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.

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.

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.

> 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 somewhat 
frustrating that invariants for example must be handled something like this:

// Or would this be 'enum' in D2?  lol
const invariantBody = "{ some code blah blah blah }";

version(D2)
    mixin("invariant() " ~ invariantBody);
else
    mixin("invariant " ~ invariantBody);

It's times like this when you kind of wish for a "stupid" preprocessor.

> 3. Any thoughts on how to programatically do all the conversions?

Start with DParser, I'd guess.  Or one of the other D parser projects. 
You'd need semantic analysis for more than the simplest tasks, though.

> 4. Would this be enough for D1 library maintainers to move to D2?

Not for me, no.  I won't move to D2 until it's actually complete.