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)
