On Tuesday, 3 November 2015 at 08:22:37 UTC, Johannes Pfau wrote:
>
> I guess it's to be compatible with the latest DMD, LDC and GDC. GDC currently only provides the 2.066.1 frontend.

this makes sense.
unfortunately often it happens that i pull in one or the other library that just happens not
to work on ldc or gdc and its over my head to fix it => stuck with dmd.


i like you'r "crazy idea", i think the ecosystem could greatly benefit from tackling this problem at its root.

On Tuesday, 3 November 2015 at 08:08:28 UTC, yawniek wrote:
> i have seen many PR's and also Forum entries that deal with the problem of newer features of the compiler not being able and then patching or working around that to support older compiler versions.
>
> since it is really easy to keep up with compiler versions and even switch
> (and not many features are being removed from dmd) what are good reasons to keep backward compatiblity?
>
> the latest example i saw was replacing groupBy by a loop to keep compatiblity with 2.066.
> while not a big thing, it adds up.

Why do we keep backward compatibility ? The answer is dead simple: people need it.

The assumption that it's easy to upgrade is totally false. Upgrading to a newer version is costly. You need to test it, maybe repackage / redeploy new applications / library and monitor that every still runs smoothly. This has a cost, and the bigger you are, the higher the cost.


> since still a lot of useful features do get added into phobos at a fairly fast pace,
> would it not be better to to keep targeting just the two most recent versions and moving
> the ecosystem a little bit further.

Unless the new release has a definitive advantage for you, like a much-needed feature, that cost isn't justified, and you're better off spending time / money on things that matter to you (like new features).


> For people entering the world of D it would be much more encouraging to read a lot
> of concise code using all the nice features we have instead of just lipstick'd C.

If 2.066 is just lipstick'd C to you, you had already spend too much time having fun with D and not enough using C ;)

One thing important for people entering the D world (or any world) is as little friction as possible. And if things don't work out of the box it's a lot of friction. Backward compatibility help with that as well.

On 4/11/2015 3:12 AM, Johannes Pfau wrote:
>
> A crazy idea:
> Once gdc supports the latest frontend version we could theoretically
> adjust the dmd pull request testing to also merge dmd pull requests
> into the gdc frontend and test gdc with these frontend-only requests. We
> would then only merge dmd pull requests that build for gdc as well. Then
> we would need some hooks to also automatically pull these into gdc. Or
> we could setup the frontend as a submodule.
>


It's not a crazy idea at all.  The problem is that we will need to get the compilers in sync first, and I'm not sure that's getting any closer to being reality.

I think the number of pull requests touching the glue layer is low enough that it would work, once the CI system is set up to enforce it.

On 18 November 2015 at 09:24, Daniel Murphy via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 4/11/2015 3:12 AM, Johannes Pfau wrote:
>
>>
>> A crazy idea:
>> Once gdc supports the latest frontend version we could theoretically
>> adjust the dmd pull request testing to also merge dmd pull requests
>> into the gdc frontend and test gdc with these frontend-only requests. We
>> would then only merge dmd pull requests that build for gdc as well. Then
>> we would need some hooks to also automatically pull these into gdc. Or
>> we could setup the frontend as a submodule.
>>
>>
>
> It's not a crazy idea at all.  The problem is that we will need to get the compilers in sync first, and I'm not sure that's getting any closer to being reality.
>
>
There are many factors at play here from my side.  Some technical blockers (like the use of floating point in the front-end), some are design (where will we store data to associate the backend symbol with the frontend), some fall into the something-else category.  It may be due to the latter that the only way forward is to take the current front-end HEAD and take a much ground-up approach.