On Thursday, May 23, 2013 01:35:13 Jesse Phillips wrote: > D is stabilizing and is stable enough for many. We want to make > progress in that direction, we don't want to just halt > development like was done at D1. We have been making it less > painful to upgrade and that effort should continue and doesn't > need to be through a "no breaking changes" mandate.
What it comes down to is that breaking changes must provide a sufficiently high ROI, or they're unacceptable. The classic example of this from Walter is renaming stuff. The ROI on that is generally very small, so he's pretty much always completely against it even if he agreed that the proposed name was better. An example of where the ROI was very was in making it so that implicit fallthrough on switches was illegal. That's not just aesthetic. It catches real bugs. The trick then is figuring out with any proposed change whether the ROI is high enough to make the change worth it. And Walter and Andrei (particularly Walter) lean heavily towards thinking that the ROI on breaking changes must be very high before they're acceptable. So, anyone arguing for a breaking change has a very high bar to meet. Maybe that bar is too high sometimes, but if it's too low, then we'll never reach the point where you can reasonably expect your code to continue to compile with every new release of dmd (or at least for a long time). So, it's not the case that breaking changes are absolutely unacceptable, but it _is_ the case that anyone wanting a breaking change has to present a very strong case. And I don't think that that's necessarily a bad thing. In fact, as the language and its implementation matures, it's pretty much a necessity. - Jonathan M Davis
