"Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message news:mailman.793.1307743181.14074.digitalmar...@puremagic.com... > On 2011-06-10 14:44, Nick Sabalausky wrote: >> "Lutger Blijdestijn" <lutger.blijdest...@gmail.com> wrote in message >> news:isu365$2ao$1...@digitalmars.com... >> >> > Andrej Mitrovic wrote: >> >> On 6/10/11, Lutger Blijdestijn <lutger.blijdest...@gmail.com> wrote: >> >>> Changing a name will now break client code. >> >> >> >> The flag template suffers from the same issue. >> > >> > Not strictly, but practically yes. It's also the point of them, >> > exposing >> > this name in the api. But its *only* for those parameters, which I >> > understand are right now just 7 functions in the whole of phobos. >> > >> > With named parameters, the issue affects every function, including >> > those >> > already written without this dependency issue in mind. >> >> That's hardly an issue though. Updating callers to use a changed function >> name is trivial. I see no reason why this would be any less trivial. > > The problem is that there is no way to provide a deprecation path without > renaming functions.
What I don't see is a compelling need to provide a deprecation path when the names change. What's so hard about "Recompiling...Oh, 'foo' doesn't work and the new name is 'bar', and it's on this file/line? Ok, done." And even that isn't needed much in a stable API anyway.
