Discussion Thread: DIP 1030--Named Arguments--Final Review

[Seb]

On Thursday, 14 May 2020 at 16:59:38 UTC, Steven Schveighoffer 
wrote:
> On 5/14/20 12:18 PM, Seb wrote:
>> On Thursday, 14 May 2020 at 13:33:30 UTC, Steven Schveighoffer 
>> wrote:
>>> [...]
>> 
>> Yeah, I that would work.
>> Though the advantage of being able to write a custom body is 
>> that now you have a lot more freedom in case the new method 
>> differs from the old one by more than argument changes (e.g. 
>> semantic or ordering changes):
>> 
>> ---
>> add(int x_s, int y_s) { ... }
>> @deprecated extern(D, "argNames") add(int x_ms, int y_ms) { 
>> add(x_ms * 1000, y_ms * 1000); }
>> ---
>
> I don't think this works, because the parameter names are 
> optional.
> In other words, add(1, 2) is going to silently do something 
> else, which defeats the purpose of the deprecation.

Fair point.
I guess this is another argument for providing library author 
with a mechanism to enforce "by argument name" only.

> A deprecation of semantic meaning or position needs to be 
> handled via a different function name (like it is today).
>
> Which means a deprecated prototype is all that is needed in the 
> case of changing parameter names.

Well, my point was that argument names have the potential for a 
lot more flexibility.
Anyhow, I'm fine with a deprecated prototype/header as it would 
already be a lot better than the current status of this DIP (i.e. 
no options for deprecation).