Flag proposal

[KennyTM~]

On Jun 11, 11 05:59, Jonathan M Davis wrote:
> 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. When changing the types that a function takes or the
> number of its parameters, you can overload it. The old version gets scheduled
> for deprecation, then deprecated, and finally, it's removed. People have time
> to migrate their code. However, you _can't_ overload on parameter names. So,
> the only way that you can change a parameter's name without breaking any and
> all code that used it as a named argument is to create a _new_ function with a
> _new_ name. So, we'd have to rename entire functions just to be able to rename
> a single parameter. That's way worse than just having to deal with some
> parameter type changes or a changes in the number of arguments. Suddenly, you
> have a whole new function to remember. And currently, you can rename a
> parameter's name without breaking any code at all. So, named arguments
> _drastically_ increase the pain of renaming function parameters.
>
> - Jonathan M Davis

Why do you need to rename parameter name of a stable API?