Migrating D front end to D - post Dconf

[Jonathan M Davis]

On Saturday, May 11, 2013 18:18:27 Walter Bright wrote:
> On 5/11/2013 6:09 PM, Jonathan M Davis wrote:
> > So, we might be better of restricting how much the compiler depends on -
> > or we may decide that the workaround is to simply build the last C++
> > version of the compiler and then move forward from there. But I think
> > that the issue should at least be raised.
> 
> Last month I tried compiling an older 15 line D utility, and 10 of those
> lines broke due to phobos changes.
> 
> I discussed this a bit with Andrei, and proposed that we keep around aliases
> for the old names, and put them inside a:
> 
>     version (OldNames) {
>        alias newname oldname;
>        ....
>     }
> 
> or something like that.

Well, that particular problem should be less of an issue in the long run. We 
renamed a lot of stuff in an effort to make the naming more consistent, but we 
haven't been doing much of that for a while now. And fortunately, those 
changes are obvious and quick.

But in theory, the way to solve the problem of your program not compiling with 
the new compiler is to compile with the compiler it was developed with in the 
first place, and then if you want to upgrade your code, you upgrade your code 
and use it with the new compiler. The big problem is when you need to compile 
the compiler. You have a circular dependency due to the compiler depending on 
itself, and have to break it somehow. As long as newer compilers can compiler 
older ones, you're fine, but that's bound to fall apart at some point unless 
you freeze everything. But even bug fixes could make the old compiler not 
compile anymore, so unless the language and compiler (and anything they depend 
on) is extremely stable, you risk not being able to compile older compilers, 
and it's hard to guarantee that level of stability, especially if the compiler 
is not restricted in what features it uses or in what it uses from the 
standard library.

- Jonathan M Davis