The great compromise of the D standard library

[Bill Baxter]

Bruce Adams wrote:
> Bill Baxter Wrote:
> 
>> Bruce Adams wrote:
>>> Is this really worth the hassle? If you check Walter's recent postings sorting out const is on the list for the next release.  He know's it sucks, he started a thread on it remember. I don't think we have long to wait for the next try. He could get it wrong again but given all the feedback and some time to think maybe he's got it right this time (or at least right enough).
>> D1.0 is still intended as a long-term support, stable version of D.  So 
>> D1.0 is not going away for a while even if const turns into everybody's 
>> favorite feature of D2.0.  And even if the new const design has 
>> everybody doing backflips of joy, code written using it it will still be 
>> incompatible with D1.0, and making it compatible will still be a pain 
>> since D lacks the equivalent of something like
>>     #define invariant /*nothing*/
>>
>> --bb
> 
> That doesn't make sense to me. Surely you want your old code to work with D2.0 but I see much less need to have your shiny new D2.0 code work with D1.0. That kind of like using the C subset of C++ albeit far less extreme.

It would be a transitional measure.  If people have to maintain two 
different versions of their libraries they will be less likely to move 
to 2.0, which slows the adoption of 2.0.  People starting out afresh 
will be more likely to just stick with 2.0.

But I started thinking a separate source code translator might be a 
better approach than adding unnecessary no-op constructs to D1.x.  So 
write your code in 2.0, and use a translator to generate your D1.x 
sources off of that.  The translator would only handle those kinds of 
low-level differences that are difficult to work around with version{} 
blocks.  Like invariant(int)[] --> int[] and .idup --> dup.

--bb