Why not flag away the mistakes of the past?

[Jonathan M Davis]

On Friday, March 09, 2018 03:16:03 Taylor Hillegeist via Digitalmars-d 
wrote:

> I wasn't so much asking about auto-decoding in particular more
> about the mentality and methods of breaking changes.
>
> In a way any change to the compiler is a breaking change when it
> comes to the configuration.
>
> I for one never expect code to compile on the latest compiler, It
> has to be the same compiler same version for the code base to
> work as expected.
>
> At one point I envisioned every file with a header that states
> the version of the compiler required for that module. A
> sophisticated configuration tool could take and compile each
> module with its respective version and then one could link. (this
> could very well be the worst idea ever)
>
> I'm not saying we should be quick to change... oh noo that would
> be very bad. But after you set in the filth of your decisions
> long and hard and are certian that it is indeed bad there should
> be a plan for action and change. And when it comes to change it
> should be an evolution not a revolution.
>
> It is good avoiding the so easily accepted mentality of legacy...
> Why do you do it that way? "It's because we've always done it
> that way."
>
> The reason I like D is often that driven by its community it
> innovates and renovates into a language that is honestly really
> fun to use. (most of the time)

Any and all changes need to be weighed for their pros and cons. No one likes
it when their code breaks, and ideally, programs would work pretty much
forever without modification, but there are changes that are worth dealing
with code breakage. Part of the problem is deciding which changes are worth
it, and some of that depends on what the migration path would be. Some stuff
can be changed with minimal pain, and other stuff can't really be changed
without breaking everything. And the more D code that exists, the higher the
cost for any change. The drive to make D perfect and the need to be able to
use and rely on D code working in production without having to keep changing
it are always in conflict.

As Walter likes to say, some folks don't want you to break anything, whereas
some folks want breaking changes, and they're frequently the same people.

Ideally, any D code that you write would work permanently as-is. Also
ideally, any and all problems or pain points with D and its standard library
would be fixed. Those two things are in complete contradiction of one
another, and it's not always easy to judge how to deal with that. Sometimes,
it means that we're stuck with legacy decisions, because fixing them is too
costly, whereas other times, it means that we deprecate something, and some
of the D code out there has to be updated, or it won't compile anymore in a
release somewhere in the future. Either way, outright breaking code
immediately, with no migration process is pretty much always unacceptable.

We'll make breaking changes if we judge the gain to be worth the pain, but
we don't want to be constantly breaking people's code, and some changes are
large enough that there's arguably no justification for them, because they
would simply be too disruptive. Because of how common string processing is
and how integrated auto-decoding is into D's string processing, it is very
difficult to come up with a way to change it which isn't simply too
disruptive to be justified, even though we want to change it. So, this is a
particularly difficult case, and how we're going to end up handling it
remains to be seen. Thus far, we've mainly worked on providing better ways
to get around it, because we can do that without breaking code, whereas
actually removing it is extremely difficult.

- Jonathan M Davis