breaking changes vs legacy: how gofix solved the problem with automated code transitions

[timotheecour]

There is a dilemma of having to choose between:
A) getting stuck with bad names / apis / language issues forever
B) making painful breaking changes that breaks existing code

See recent D threads for all the polemics this creates on 
(in)stability of D.

GO avoids this dilemma with the correct approach, IMO: automation 
of code transition.
See this article for details on gofix: 
http://blog.golang.org/2011/04/introducing-gofix.html

gofix operates on the AST of the code and performs AST 
manipulations (no fragile 'sed' / regex based bash scripts!), 
followed by printing them back to the source code. This is made 
possible by gofmt, which formats source code.

Here's a snippet from the article:

"Gofix has already made itself indispensable. In particular, the 
recent reflect changes would have been unpalatable without 
automated conversion, and the reflect API badly needed to be 
redone. Gofix gives us the ability to fix mistakes or completely 
rethink package APIs without worrying about the cost of 
converting existing code."

This is what we need for D if we want to avoid getting stuck in 
this dilemma.