On Tuesday, 27 January 2015 at 03:25:59 UTC, Zach the Mystic
wrote:
On Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright
wrote:
On 1/26/2015 6:15 PM, Zach the Mystic wrote:
What's keeping you from committing to 'dfix' as the way to
solve issues like the
one in this thread?
Inertia of people being reluctant to use it. It's still work
for people to use, it's not part of their build process.
What about compiler integration? I'm talking about fundamental
language changes. Why would people use it if it didn't have
official backing and wasn't part of the compiler package? In
this post:
http://forum.dlang.org/post/uimpnhiweuitnnbeq...@forum.dlang.org
... I said: 'For example, let's say dfix is included with the
compiler package.
Now you get an error, saying: "Error: `@nogc` is no longer
accepted, but can be automatically replaced with `nogc`. Run
dfix
on this file? (y/n)"... or whatever is deemed the secure
approach
to this feature.'
That's what I mean by "commiting to dfix."
This has come up before. I believe if was at DConf 2014 that
Walter answered this question. If I remember, the gist was that
Walter didn't like the idea that the compiler could rewrite a
user's code, he seemed kinda "creeped" out to think that a
compiler would do this. Then someone suggested the compiler
could generate some type of awk expression that the programmer
could run to modify the code. Anyway, just relaying what I
remember.
IMO, if the rewrite tool was done well it could be a benefit. I
think a preview of the changes would be a great feature. But I
also understand Walter's point.
