"H. S. Teoh via Digitalmars-d" wrote in message
news:[email protected]...
From an end user's POV, though, two years does seem like a short time. I
mean, I have C/C++ projects dating from 20 years ago, and you wouldn't
believe it, but almost all of them compile with no change on a modern
compiler. Granted, the comparison isn't altogether fair, since D is
changing a lot faster than C/C++, but still, 2 years is quite short from
that POV. Not everybody is constantly trying to compile code with git
HEAD and fixing compiling errors on every personal pet project they
have, that, on the off-chance, might stop compiling after 2 years.
I don't think it's reasonable to support those expectations in phobos. You
don't need to constantly compile with git HEAD, just upgrade in smaller
steps than 2 years.
Perhaps it's time to reconsider the length of the deprecation cycle,
from an end user's POV, rather than from the POV of the D devs who can't
wait to junk the old stuff and move on to the new.
Maintaining only junk has a cost, and development is slow enough as it is.
Alternatively, we should have a "compatibility mode" for the compiler /
Phobos, where certain parts of the code are version'd out as they get
deprecated, but you can get them back by using an appropriate version
declaration:
This works reasonably well for Phobos, but I don't know how to do this
in the compiler without ending up with an ugly plate of unmaintainable
spaghetti.
I don't think it works well for either, but it really doesn't work for the
compiler. Everything depends on everything else and often motivation for
actually getting around to removing features comes from how much of a pain
they are to maintain.
