Phobos - breaking existing code

[Daniel Murphy via Digitalmars-d]

"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.2437.1417219611.9932.digitalmars-d at puremagic.com...

> 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.