Phobos - breaking existing code

[Jonathan M Davis via Digitalmars-d]

On Sunday, November 30, 2014 07:28:57 H. S. Teoh via Digitalmars-d wrote:
> On Sun, Nov 30, 2014 at 03:03:23AM -0800, Jonathan M Davis via Digitalmars-d wrote:
> > 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.

Yeah, and AFAIK, no one ever managed to convince Walter that that needed to
be changed. There were DIPs on the matter, but I don't recall if any made it
to the PR stage or not. I know that Martin was looking at it at one point,
and he wrote one of the DIPs, but AFAIK, he hasn't touched the issue
recently.

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

That would create symbol conflicts as long as the symbol was kept around,
which is more of a problem in some cases than others. It also leaves cruft
in the library. So, ideally, we wouldn't leave stuff like that around, but
as the language and standard library mature, we are going to need to
seriously look at having two year old code work with an up-to-date compiler
and standard library. Thus far, the approach has been that folks really need
to be maintaining their code at least occasionally, and we've supported
moving code forward clearly via the deprecation cycle, but code that isn't
touched for years wasn't really even considered a legitimate use case by
many of us - and yebblie's suggestion of updating to an intermediary
compiler does solve the problem rather nicely.

So, I don't know. As a maintainer of Phobos, I'd much prefer to not leave
cruft around, since it does make the library worse for anyone who is
maintaining their code, and I don't know how much sympathy I have when code
isn't even built with a newer compiler for over two years. But we do want to
be a lot more stable than we are...

Maintaining stability while avoiding stagnation and cruft is always a
challenge.

- Jonathan m Davis