Some things that really should be fixed, don't get fixed
because of a
paranoid fear of breaking code. And this tends to happen with
the issues
that can give nice warning messages and are easy to fix...
Yet there are still enough bugs that your code breaks every
release anyway.
We need to lose the fantasy that there is legacy code which
still compiles.
Anything more than a year or so old is broken already.
Backward compatibility is more like a spectrum than a
threshold. Not having it now is not an argument to cease
pursuing it.
Exactly, it's a spectrum. But at any given time, the whole
language and library are not at a single point on the spectrum.
Some things are frozen, others in practice are not. And the
problem is that D has historically acted as if everything was the
same, which just doesn't work.
I think three levels of forwards compatibility are useful to
consider:
1. Frozen. Things that you can absolutely rely on, we will NEVER
change it under any circumstances. Any bugs in the design will
never be fixed.
2. Stable. We will attempt to minimize changes, but we don't
guarantee your code will never break. (It may break in order to
prevent breakage of things in case 1, for example). We can
guarantee a deprecation path in most cases.
3. We will avoid gratuitous changes, but it will almost certainly
change in the future.
And what we want to do, is gradually move as many things as we
can from category (2) into category (1), and from (3) into (2).
I'd like to see us giving a lot more guarantees, rather than
trying to keep promises we never actually made.
