Phobos - breaking existing code

[Walter Bright via Digitalmars-d]

On 11/30/2014 7:28 AM, H. S. Teoh via Digitalmars-d wrote:
> 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*.

Yup. Consider the fnmatch => globMatch change. Just edit the name, right? 
Easy-peesy, right? But:

1. the guy given the job of updating the software is not the guy who wrote it - 
he doesn't know what the code is intending to do

2. He gets "fnmatch is undefined"

3. there's no documentation for fnmatch anymore. He has no idea what fnmatch is 
supposed to do. Now he's got to embark on some sort of forensic search through 
old versions of the compiler, and not having much clue which ones to look at

4. he figures out what it does, then starts poking through the Phobos 
documentation looking for something that might work

5. he finds globMatch, it looks like it'll work

6. hopefully he's got a good test suite to verify that it is actually the 
correct replacement

A simple name change has turned into a fair amount of work.


> 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

Keeping around a deprecated alias translating the old symbol to the new one is a 
good approach. For a more detailed message, instead of the @disabled 
enhancement, a simpler way is:

   void fnmatch()(...) {
     static assert(0, "use globMatch instead of fnmatch");
   }