On Saturday, 26 July 2014 at 01:24:31 UTC, Walter Bright wrote:
On 7/25/2014 6:13 PM, Mike wrote:
IMO breaking changes are justified if the changes fix a design
flaw in the
language or the changes break code that should have never been
permitted.
Ironically, today I'm being vehemently argued with for both
breaking code and not breaking code.
Isn't that to be expected in your position? There will be
consequences if a decision is made to not break code, and there
will be consequences if a decision is made to break code.
Principles like the 2 I mentioned would help, but Brian's work
(std.d.lexer, DScanner, etc...) is showing immense value here in
creating a "go tool fix"-like utility [1]. If we (that includes
me) would support it and make it a priority, we wouldn't have to
take such a hard-line stance on breaking changes.
Mike
[1] http://golang.org/cmd/fix/
