On Saturday, 9 March 2013 at 06:22:15 UTC, deadalnix wrote:
> Many things can be done to mitigate that stuff.

Thank you,

Now we need to come up with ways to help facilitate making these changes.

> The first, obvious one, is to provide a version of the compiler without the fix (bug with other fixes that don't break most code).

This is supposed to be addressed by the new release process. I don't think helps in mitigation, it is avoidance which has some positives in its own right.

> A second thing to do is to adapt phobos to take rvalues at several places. (This have the problem that ranges have unspecified behavior when passed by value).

Phobos makes use of itself and so a disruption in the language will cause Phobos to show issue. If we adjust Phobos to work with itself/unittests, things we miss are likely because we didn't have a complete set of unittests on behavior?

Since unittest won't cover every case, maybe we could try a tag on the bugzilla entry to indicate Phobos was changed as a result. A comment including the need changes is added. When reviewing a pull request for such one would theorize on possible other implications and can request further changes if needed.

Something similar can be done for Phobos changes, as accepting a range by rvalue could have other implications and thus would need a good statement of breaking change.

> Finally, an useful error message, with a workaround proposal would be welcome,
> Error, range used as lvalue. You may want to do BLAH to solve that.

Yeah review should look for good error messages. Though we may want to be careful about suggestions (too many options, too long to describe, only relevant to broken code and not code originally incorrect).

On Saturday, 9 March 2013 at 07:19:34 UTC, Dicebot wrote:
> Any well-thought change is the way forwards as it improves the language. And is actually a regression.

I disagree with your definition of regression and prefer:

"A return to a former or less developed state."

> You tend to separate "good regressions" and "bad regressions" but there is no possible way to separate those unless you are deep into D development. We have no spec (reference compiler is the spec) and for an end user all those break code equally surprisingly, having good intentions does not help.

I'm not talking hypothetical here, my experience. Update opEquals and toHash so they are const/pure/nothrow/fairy dust I'll grumble as I now need to update code I didn't write so don't understand the ramifications of my changes, but so be it. But to have to change it all back the next release because it was too disruptive and there might be a different approach that needs taken, that brings grumbling to a whole new level. (I'm not as annoyed as I make it sound, but I certainly am not sounding annoyed enough for many)

> And clearly because changes are _needed_ and bug-fixing can't be stopped, there needs to be clear accepted approach of "how do we break stuff" instead of "breaking stuff is bad". I have attempted to suggest one such approach.

And that is what it comes down to, how do we do it. The Utopia, all non-breaking changes are applied to all past releases. We need a middle ground, somewhere probably not near the middle. And gave my approach.

> This is already accepted as part of new release process, but, unfortunately, does not seem to be executed in practice.

Shouldn't we be trying to get this practiced first? Your suggestion still relies on maintaining something other than the current dev branch. If we can't get this, what are we left with?

> Problem with maintaining only last 2 releases is that they come out pretty fast, sometimes as fast as once in two months. That does not leave enough time to adapt without sacrificing mundane development.

You can remain on the same compiler version you initially programmed for. I'm all for a Long term support like approach, but I see that as a secondary thing to properly releasing a dev.

> It is actually the other way around - I want _more_ breaking changes :) And that won't happen while two conflicting goals are pursued at the same time.

A Long Term Support does not allow for more breaking changes, it only delays how long before you have to deal with it. There are only two options to not have breaking changes, the C++/Windows approach (which fails) and never updating your program. But we can do a better job managing expectations.