Flag proposal

Nick Sabalausky a at a.a
Fri Jun 10 14:58:53 PDT 2011


"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.791.1307742081.14074.digitalmars-d at puremagic.com...
> On 2011-06-10 14:28, 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 really. There's a big difference between changing the type name and
> changing the parameter name. You can freely change the parameter name 
> without
> changing the type name. Also, you can overload on type names, allowing you 
> to
> deprecate the old name and replace it with a new one gradually. You 
> _can't_
> overload on parameter names, so you _can't_ have a deprecation path with 
> named
> arguments without renaming the function itself, which is _way_ worse. The
> difference between the two isn't even comparable.
>
> - Jonathan M Davis

I *really* think that whole issue is a complete triviality, but:

1. Maybe you *could* allow overloading on name, forcing at least that 
particular param to be named:

void foo(int oldName);
void foo(int newName);

foo(oldName:7); // Ok
foo(newName:7); // Ok
foo(7); // Error

void bar(int num);

bar(num:7); // Ok
bar(7); // Ok

2.  This:

void foo(int newName);
deprecated void foo(int oldName);

foo(oldName:7); // Error: Deprecated
foo(newName:7); // Ok
foo(7); // Ok





More information about the Digitalmars-d mailing list