Compiler updating user code

[Frustrated]

On Friday, 14 March 2014 at 05:15:05 UTC, Manu wrote:
> So it comes up fairly regularly that people suggest that the 
> compiler
> should have a mode where it may update user code automatically 
> to assist
> migration to new compiler versions.
>
> I'm personally against the idea, and Walter certainly doesn't 
> like it, but
> it occurred to me that a slight variation on this idea might be 
> awesome.
>
> Imagine instead, an '-update' option which instead of modifying 
> your code,
> would output a .patch file containing suggested amendments 
> wherever it
> encountered deprecated code...
> The user can then take this patch file, inspect it visually 
> using their
> favourite merge tool, and pick and choose the bits that they 
> agree or
> disagree with.
>
> I would say this approach takes a dubious feature and turns it 
> into a
> spectacular feature!
>
> Language changes are probably easy enough to handle, but what 
> about cases
> of 'deprecated' in the library?
> It's conceivable that the deprecated keyword could take an 
> optional
> argument to a CTFE function which would receive the expression 
> as a string,
> and the function could transform and return an amended string 
> which would
> also be added to the output patch file. This way, the feature 
> could
> conceivably also offer upgrade advice for arbitrary library 
> changes.
>
> Considering the advice in the context of a visual diff/merge 
> window would
> be awesome if you ask me.

How difficult would it be to be able to configure the compiler 
for various updates directly?

What I mean is that suppose a few fixes were made and some 
breaking changes were made.

Could the compiler itself be configured in such a way(at least 
for most "breaking changes") that the user could switch the 
change on and off yet keep the fixes.

Example:

Suppose final by default and several bug fixes are added to 
version X + 1. If the user could configure the compiler so that 
he could simply keep the fixes but not have final by default(a 
sort of version x + 0.5) then he would get the benefit of the 
fixes without the breaking change.

I think it would probably be a maintenance nightmare and be 
extremely hard to implement because it is not easy to keep 
changes.

There are a few ways to think about it though. If the compiler 
kept every version it had in it's binary and the user could do 
-version2.063, for example, it would be easy to select the 
version. One can already download the version one wants so this 
isn't really a great solution.

But what is the differential between most versions? Just fixes 
and breaking changes. So is the compiler kept fixes and 
changes(sort of patches) in the binary that it could apply to 
itself and a dependency list is created it might be easier to 
manage.

Possibly with the proper software and methodologies it could be 
done. It would, at least, solve the problem. If someone didn't 
want some breaking change they simply could remove it from the 
compiler: -removechange1435 (maybe change 1435 is final by 
default) which reverts the compiler back to before that change 
BUT keeps all the fixes up to the current version that are not 
dependent on that change.


Another concept,

In windows, for example, you can install updates that "fix" 
problems. Most of the time you can roll back the changes.

Suppose one can do the same with the compiler. Instead of 
downloading a new version of a compiler one simply downloads the 
"fixes" and "changes". If a change is added that one doesn't like 
they just uninstall it.

This too would be difficult in some ways since compilers are 
generally not designed in such modular ways but it might be 
possible. (I guess essentially including the source code in the 
compiler and giving the compiler the ability to compile itself 
with the patches would be a way to achieve this)