if(arr) now a warning

[Jonathan M Davis via Digitalmars-d]

On Friday, May 01, 2015 10:40:46 Daniel Kozak via Digitalmars-d wrote:
> I do not want to change any of the issue above, I just do not understand why
> some breaking changes are OK, and some other are not so ok.

Well, fixing bugs often results in breaking changes. Sometimes, it's
determined that something causes enough bugs that we make it illegal (e.g.
implicit fallthrough in switch statements), and that would be a breaking
change (though in principle, it finds and prevents enough bugs to be worth
it). Sometimes, we're forced to make changes in the language to enable
something we want or need to do or to make an existing feature work
correctly, and that can result in breaking changes. Sometimes, we decide
that a previous design decision was enough of a mistake to be worth changing
even though it breaks code. There are a number of reasons for it.

Ultimately, the question is whether the changes are worth the problems that
the breakage causes (which often depends on how much code is likely to break
and how critical it is that the change be made; e.g. fixing a bug is pretty
much always going to be worth the breakage, whereas making a design change
often wouldn't be). And whether the change is made tends to depend on who's
involved in the decision. Some devs are more willing to make breaking
changes than others, and it's not always clear whether something is really a
bug or just an unfortunate result of other design decisions. Walter tends to
reject most breaking changes, but he might consider something to be a bug
that needs to be fixed whereas someone else thinks that it's legitimate
behavior. And Walter doesn't review every pull request, so sometimes,
breaking changes are made without his knowledge or consent.

We make _far_ fewer breaking changes than we used to, and the bar has been
raised considerably, but we do upon occasion make breaking changes when we
think that it's worth it, and that's always going to be on a case-by-case
basis. So, it's very hard to give a definitive answer as to what is and
isn't an acceptable breaking change. It really depends on the change in
question.

In general, I think that most breaking changes occur due to regressions that
aren't caught, in which case, they're bugs, not purposeful changes. And
while we're doing better at catching and preventing regressions, we
definitely don't get them all. We really need more folks trying out the
betas with their projects and reporting any issues that they find in order
to get anywhere near catching them all (and we'll probably never catch 100%
of them, particularly if a regression affects only rare cases). So,
frequently, code breakage is completely accidental.

- Jonathan M Davis