<p dir="ltr">On 21 Jul 2015 00:00, "Martin Nowak via Digitalmars-d" <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
> On Monday, 20 July 2015 at 09:10:13 UTC, Iain Buclaw wrote:<br>
>><br>
>> I just have one request.  We need to designate a supported version of the compiler (2.069?) as the base to which we convert and maintain compatibility for, and do not introduce any new features after that point.<br>
><br>
><br>
> I don't fully understand what you're asking for.<br>
> Can you tell us what problem you're trying to address instead of which solution to apply.</p>
<p dir="ltr">1. If you want ddmd to be compilable by both gdc and ldc then you can't introduce any new features to the ddmd codebase post conversion.</p>
<p dir="ltr">The work you've left me is an added burden that was ultimately welcome, but unasked for. So expect things to halt on my side for some time as I'm going through a partial rewrite.</p>
<p dir="ltr">2. Simplifies bootstrap for porting to self-hosted D.</p>
<p dir="ltr">Though the gdc compiler is available in Debian on all supported platforms - some 16 in total - the library is still only being built on x86 and ARM, because of lack of testing or build failures.</p>
<p dir="ltr">Having the last C++ frontend being able to build the latest D frontend allows the transition for these targets that need their runtime library ported and tested easier.  The reality still is that C++ has the upper hand for being more portable, but there should be no reason why we can't run everywhere C++ runs granted there is an OS.</p>
<p dir="ltr">3. Force stability language through codebase.  Maybe ddmd will be a bad example as it's pretty much written in the style of a Poor-mans-C++-in-D.  But not breaking language compatibility between 2.068 and LATEST should help reduce regressions between versions.  Most people I've talked to agree.</p>
<p dir="ltr">Iain.</p>