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.

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.

Sounds like a cool idea. But not as part of the compiler. Its more of a use case for compiler as a library ;)

On Friday, 14 March 2014 at 07:10:43 UTC, Rikki Cattermole wrote:
> 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.
>
> Sounds like a cool idea. But not as part of the compiler. Its more of a use case for compiler as a library ;)

I believe the first candidate is `dub fix` - by analogy with `go fix`. I also believe this kind of tool would be great for handling language changes. However, it seems implementing and maintaining it is quite a lot of work.

"Manu" <turkeyman@gmail.com> wrote in message news:mailman.105.1394774104.23258.digitalmars-d@puremagic.com...

> 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!

If you're using version control, these are practically the same thing.  If not, you have bigger problems.

> 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.

Simple updates could be trivially scripted, but more complex ones would need full re-write rules.  All of this is fairly easy to do, and is a simple form of auto-refactoring code.

Once we have a full-featured auto-formatter we'll be most of the way there. 

On Friday, 14 March 2014 at 11:44:21 UTC, Daniel Murphy wrote:
> "Manu" <turkeyman@gmail.com> wrote in message news:mailman.105.1394774104.23258.digitalmars-d@puremagic.com...
>
>> 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!
>
> If you're using version control, these are practically the same thing.

Yeah, I don't understand why it matters whether it's a change or a patch. Either way, all changes become patches in VCS. Who would let an automated tool make source changes without using VC, or at least having made a manual backup?

Also, making a direct change allows the user to use whatever diff software / version control software they like.

On 2014-03-14 05:14:52 +0000, Manu <turkeyman@gmail.com> said:

> 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!

If you're using a version control system, it's probably simpler to just apply the patch automatically and then review it like you'd review any change you're ready to commit, while tweaking the changes if needed.

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. Currently the frontend remembers only the file and line of any token it finds. You can't implement a refactoring with that. Last time that came in in a discussion (about error messages showing the exact location of the error), the idea was shut down on the ground that storing better location info would slow down the compiler.


> 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.

Xcode has a refactoring for transitioning to ARC, and it works by presenting you a merge view of the changes, which you can edit, before saving them. I'm sure other IDEs can do that too.
http://cdn5.raywenderlich.com/wp-content/uploads/2012/01/Review-Changes.png

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 14 March 2014 22:07, John Colvin <john.loughran.colvin@gmail.com> wrote:

> On Friday, 14 March 2014 at 11:44:21 UTC, Daniel Murphy wrote:
>
>> "Manu" <turkeyman@gmail.com> wrote in message news:mailman.105.1394774104.23258.digitalmars-d@puremagic.com...
>>
>>  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!
>>>
>>
>> If you're using version control, these are practically the same thing.
>>
>
> Yeah, I don't understand why it matters whether it's a change or a patch. Either way, all changes become patches in VCS. Who would let an automated tool make source changes without using VC, or at least having made a manual backup?
>

Because Walter is acutely allergic to the idea of a tool that modifies your
source code. I might also have uncommitted changes, and not particularly
feel like stashing them for the moment (less easy in other VCS's).
I might also not want to apply all the changes, only some of them. Surely
it's easier to merge the ones I want after visual approval, than reverting
the ones I don't want after having gone to the effort of stashing my local
changes to make a clean slate to work with...

Also, making a direct change allows the user to use whatever diff software
> / version control software they like.
>

I'm not sure how a patch file restricts them to a particular merge program or VCS...

"Michel Fortin"  wrote in message news:lfurh8$qae$1@digitalmars.com... 

> 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. Currently the frontend remembers only the file and line of any token it finds. You can't implement a refactoring with that. Last time that came in in a discussion (about error messages showing the exact location of the error), the idea was shut down on the ground that storing better location info would slow down the compiler.

Yeah, we'll have to do this at some point.

On Friday, 14 March 2014 at 12:23:01 UTC, Manu wrote:
> On 14 March 2014 22:07, John Colvin <john.loughran.colvin@gmail.com> wrote:
>
>> On Friday, 14 March 2014 at 11:44:21 UTC, Daniel Murphy wrote:
>>
>>> "Manu" <turkeyman@gmail.com> wrote in message
>>> news:mailman.105.1394774104.23258.digitalmars-d@puremagic.com...
>>>
>>>  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!
>>>>
>>>
>>> If you're using version control, these are practically the same thing.
>>>
>>
>> Yeah, I don't understand why it matters whether it's a change or a patch.
>> Either way, all changes become patches in VCS. Who would let an automated
>> tool make source changes without using VC, or at least having made a manual
>> backup?
>>
>
> Because Walter is acutely allergic to the idea of a tool that modifies your
> source code. I might also have uncommitted changes, and not particularly
> feel like stashing them for the moment (less easy in other VCS's).
> I might also not want to apply all the changes, only some of them. Surely
> it's easier to merge the ones I want after visual approval, than reverting
> the ones I don't want after having gone to the effort of stashing my local
> changes to make a clean slate to work with...
>

I appreciate it would be convenient, but changing compiler versions and patching up the code is a major enough update to justify a branch IMO, let alone just a commit or stash.

Anyway, I don't think it matters that much either way.

Admittedly my experience is limited to git and mercurial, both of which deal with these sorts of situations trivially.

> Also, making a direct change allows the user to use whatever diff software
>> / version control software they like.
>>
>
> I'm not sure how a patch file restricts them to a particular merge program
> or VCS...

I suppose not. I was assuming that there might be different standards for patch files.

On 14 March 2014 22:31, John Colvin <john.loughran.colvin@gmail.com> wrote:
>
>
> I appreciate it would be convenient, but changing compiler versions and patching up the code is a major enough update to justify a branch IMO, let alone just a commit or stash.
>
> Anyway, I don't think it matters that much either way.
>
> Admittedly my experience is limited to git and mercurial, both of which deal with these sorts of situations trivially.
>

You may be right. I just thought of it as a solution to a suggestion that
comes up frequently, but is considered obnoxious by some people.
DMD is no stranger out outputting files beside the compilation output, like
the .json file for instance. I would personally find the patch approach
convenient, and it could subvert some other issues, like what if there is
no write access to the source tree?