Migrating D front end to D - post Dconf

[David Nadlinger]

On Saturday, 11 May 2013 at 18:15:22 UTC, Daniel Murphy wrote:
> If we use them in the compiler, we effectively freeze them.  We 
> can't use
> the new modules, because the old toolchains don't have them.

Fair enough, but in such a case we could always add the parts of 
them we really need to the compiler source until the module is 
present in the last supported version. The critical difference of 
this scenario to your approach is that the extra maintenance 
burden is limited in time: The code is guaranteed to be removed 
again after (say) a year, and as Phobos stabilizes more and more, 
the total amount of such "compatibility" code will go down as 
well.

> We can't fix
> old broken modules because the compiler depends on them.

I don't see your point here:
   1) The same is true for any client code out there. The only 
difference is that we now directly experience what any D library 
writer out there has to go through anyway, if they want their 
code to work with multiple compiler releases.
   2) If a module is so broken that any "fix" would break all 
client code, we probably are not going to use it in the compiler 
anyway.

> If you add code to
> work around old modules being gone in later versions, you 
> pretty much end up
> moving the source into the compiler after all.

Yes, but how often do you think this will happen? At the current 
point, the barrier for such changes should be quite high anyway. 
The amount of D2 code in the wild is already non-negligible and 
growing steadily.

> If we only need to be able to compile with a version from 6 
> months ago, this
> is not a problem.  A year and it's still workable.  But two 
> years?  Three?
> We can get something right here that gcc got so horribly wrong.

Care to elaborate on that?

David