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
