Flag proposal

[Jonathan M Davis]

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