Phobos - breaking existing code

[H. S. Teoh via Digitalmars-d]

On Sun, Nov 30, 2014 at 03:03:23AM -0800, Jonathan M Davis via Digitalmars-d wrote:
[...]
> be. I completely agree that we should be trying to reduce code
> breakage even over longer periods of time (and I think that we
> definitely _have_ reduced it, even if it's not by enough to allow
> Walter to compile his two year old microemacs code without using any
> compilers in between), but I also think that the expectation that old
> code should compile several years later with no changes and without
> using any compilers in between is higher than reasonable. I'm not sure
> that that even works with C++ compilers, much as it should -
> especially when you go from C++98 to C++11 or C++14, and since D is
> continually in flux (even if it's a lot less flux than it used to be),
> doing something like going from 2.058 to 2.066 is a lot like going
> from C++98 to C++11.

FWIW, I have C++ code dating from 10 years ago that still compiles with
C++11. Granted, I needed to fix a thing or two here and there, but they
were pretty straightforward (compiler warnings / errors told you exactly
why the code doesn't work anymore). But then again, it's not like C++11
replaced an entire standard library module in the process -- they did
introduce new and better modules but old ones were kept around.


> To really have full stability, we'd pretty much have to freeze
> everything and change nothing beyond bug fixes, and we're definitely
> not doing that. Heck, simply introducing a new function to Phobos can
> break existing code, because it can create a symbol conflict.

Speaking of which, this problem is made a lot worse than it could be,
because currently private symbols in imported modules are included in
the overload set, so introducing a *private* symbol can break unrelated
user code downstream. Ugh.


> It's an easy fix, but stuff like that makes it nigh on impossible to
> guarantee that we won't break two-year old code.
[...]

I think the complaint was not so much the fact that the code broke, but
the fact that it broke *without any clue as to how to fix it*. Now, if
we had something like @disable with an optional message, we could do
something like:

	@disabled("Please use globMatch instead") auto fnmatch(...);

At least in theory, this would fix the problem. Of course, in practice,
things rarely work out so nicely except in retrospect. :-P


T

-- 
MAS = Mana Ada Sistem?