dmd 2.068, 2.069, 2.0xx Evil Plan going forward

[Iain Buclaw via Digitalmars-d]

On 21 Jul 2015 00:00, "Martin Nowak via Digitalmars-d" <
digitalmars-d at puremagic.com> wrote:
>
> On Monday, 20 July 2015 at 09:10:13 UTC, Iain Buclaw wrote:
>>
>> 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.
>
>
> I don't fully understand what you're asking for.
> Can you tell us what problem you're trying to address instead of which
solution to apply.

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.

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.

2. Simplifies bootstrap for porting to self-hosted D.

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.

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.

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.

Iain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150721/a0e1af5e/attachment.html>