Flag proposal

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.793.1307743181.14074.digitalmars-d at puremagic.com...
> On 2011-06-10 14:44, Nick Sabalausky wrote:
>> "Lutger Blijdestijn" <lutger.blijdestijn at gmail.com> wrote in message
>> news:isu365$2ao$1 at digitalmars.com...
>>
>> > Andrej Mitrovic wrote:
>> >> On 6/10/11, Lutger Blijdestijn <lutger.blijdestijn at 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.