On Wednesday, 22 May 2013 at 23:52:25 UTC, Jonathan M Davis wrote:
What it comes down to is that breaking changes must provide a
sufficiently high
ROI, or they're unacceptable.
And what was the reason to take this as an axiom? What makes you
think core D developers can decide for all other D users what is
sufficiently high ROI and what is not? For _everyone_. And how do
you define "sufficiently high"?
That is exactly what I call "intention-based stability". Your
intentions are good and goal is noble but lack of strict rules
make it essentially useless. Problem is, "stability" is not some
abstract merit that can be measured. It is a certain expectation
with pragmatical use cases.
One good way to make compiler/language stable is to ask "Why do
people need it stable? What problems does it solve? How our
guarantees help?". And most common answer for first question I
have encountered so far : "Because people hate to spend time in
the middle of project to fix unexpected issues from already
working code base". Note that this has nothing to do with
features, or ROI, or correctness, or whatever. It is all about
expectation of a change. And despite all efforts, D falls
miserably here. See current beta mailing list for several
examples of what should have never happened in real stable
development process.
