Smooth transition to D2 for Tango users?

Jason House jason.james.house at gmail.com
Sun Sep 21 08:55:48 PDT 2008


Bruce Adams wrote:

> Maybe I've misunderstood but what I thought was being asked for was for
> the D1.0
> language to be changed to accept D2.0 syntax and ignore it at some point
> within blocks
> marked as D1.0 versions.
> This would mean that for a D1.0 compiler vendor to comply with the
> standard the
> D1.0 compiler would have to extended to parse D2.0.
> A bit like asking a C compiler to ignore C++ class definitions.
> Having D2.0 compilers accept D1.0 syntax in D1.0 version sections makes
> more sense.

I've proposed many things :)  My ultimate goal is for a smooth transition
between D1.0 and D2.0.  For that to happen requires providing a path for
Tango users and therefore Tango.  Obviously, that's not the only important
project, but it does have the largest user base.  I have to assume that a
smooth transition for a project as large as Tango means it would exist for
other D1 projects.

There are many ways to achieve that ultimate goal:
1. Backward compatibility (D2 parsing of all D1 code)
2. Forward compatibility (D1 parsing of a subset of D2 code)
3. version(D1), version(D2), with lightened parsing restrictions
4. Replace D's pre-processor
5. 3rd party pre-processor
6. D2 to D1 converter

Below I tried to quickly make a list of pros and cons of each approach
before having to run out the door.  I've probably missed an alternative and
many pros and cons.  I hope we can find an alternative, or combination of
alternatives, that allow this to happen.  

#1: (backward compatibility)
pros:
* Enables a single D1 code base that compiles with either D dialect
* Allows legacy code to compile and run without modification
* Least effort for library maintainers
cons:
* Requires allowing exceptions to const/invariant rules
* Requires Walter to commit to the approach
* Walter has previously stated that he felt C was held back by backwards
  compatibility.  It's unlikely that he'd support this approach.

#2: (forward compatibility)
pros:
* Enables a single "D1" code base that compiles with either D dialect
* Partial adoption makes other alternatives easier/simpler
cons:
* Allows D1 to look like D2 code
* Requires Walter's to commit (at least partially) to the approach

#3: (version(D1), version(D2))
pros:
* Easy to spot code intended for D1 and D2
* Allows gradual phasing out of old D versions
cons:
* Can't wrap function prototypes in a version statement by themselves
* Will cause massive code duplication and restrict code maintainability
* Requires Walter to commit to one of two altrnatives:
  * Parsing of alternate D dialects in one D dialect
  * Ignoring of code within these special version blocks
* Fraction of code that must be covered with version statements

#4: (Replace D's pre-processor)
pros:
* Allows versioned function prototypes without duplicating all containing
  code.
cons:
* Requires Walter to commit to this approach
* Pre-processor is more C-like and Walter has already stated he's against
  that

#5: (3rd party pre-processor)
pros:
* Allows versioned function prototypes without duplicating all containing
  code.
* Unrestricted by D language design or Walter's choices
cons:
* Non-standard and unlikely to gain wide adoption
* Makes use of library code tougher because of extra tools and compilation
  steps.  Could be alleviated by distributing 3 code bases.

#6: (D2 to D1 converter)
pros:
* Enables a single D2 code base that compiles with either D dialect
cons:
* Impossible to downconvert all code automatically.  
* Must be combined with another approach



More information about the Digitalmars-d mailing list