Compiler updating user code

[Andrej Mitrovic]

On 3/14/14, Michel Fortin <michel.fortin at michelf.ca> wrote:
> But before you can consider building such a tool, you'll have to
> convince Walter that the locations of tokens should be tracked more
> precisely in the frontend.

Note that if this tool is built-in to the compiler (as a feature) it
will have some big drawbacks:

1) It's only released when the compiler is released. If the feature
has regressions you are tied to the DMD release schedule before you
can release a fix.

2) The feature will only work with the latest compiler. In other
words, if you want to update a 2.070 codebase to 2.072, you will
actually need to use two compilers. The porting tool released with DMD
2.071 to port 2.070 to 2.071, and the tool released with 2.072 to port
2.071 to 2.072.

What I mean is, the parser in DMD v2.072 might not be able to parse
code written for v2.070. But if the conversion tool was separate from
both the compiler and its internal parser then you could make the tool
work for an entire range of codebase versions, and e.g. directly port
a v2.070 codebase to 2.080.

You could even back-port code. Let's say you've started using 2.070
for over a month, and you hit a major performance regression. You're
short on time, you need to release your app to the public
(deadlines..), but you have to wait for the fix. With the tool you
could potentially be able to port the code back to 2.069 which didn't
have the performance regression.

This is all theoretical so far.

Anyway if someone wants to build it in the compiler, I won't stop them.