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

[Seb]

On Thursday, 14 May 2020 at 13:33:30 UTC, Steven Schveighoffer 
wrote:
> On 5/14/20 9:20 AM, jmh530 wrote:
>> On Thursday, 14 May 2020 at 12:03:13 UTC, Petar Kirov 
>> [ZombineDev] wrote:
>>> [snip]
>>>
>>> [1]:
>>> /sandbox/main.d(5): Error: `library.copy` called with 
>>> argument types `(string, string)` matches both:
>>> /sandbox/library.d(1):     `library.copy(string source, 
>>> string destination)`
>>> and:
>>> /sandbox/library.d(7):     `library.copy(string source, 
>>> string distinasion)`
>> 
>> Interesting that it only mentions two of them and not all of 
>> them. If you comment one of them out, then it mentions the 
>> other.
>> 
>> To your suggestion above, it's unclear if you are suggesting 
>> that the compiler read the deprecation message and change 
>> behavior somehow based on it. There is nothing stopping you 
>> from providing detailed deprecation messages today. Expanding 
>> on Seb's example, you could have something like below.
>> 
>> void foo(int x, int y) { ... }
>> 
>> deprecated("Parameters renamed: `xVal` -> `x` | `yVal` -> `y`")
>> extern(D, argNames)
>> void foo(int xVal, int yVal) { ... }
>> 
>> The extern(D, argNames) is from Seb and is what would tell the 
>> compiler to only allow calling foo with keyword arguments.
>> 
>> Thinking on it, you could make this even more general and have
>> extern(D, positionOnly)
>> extern(D, keywordOnly)
>> which would force either positionOnly or keywordOnly syntax. 
>> That would resolve any concerns that I have.
>
> I don't think the extern(D, argNames) idea works. Both foos are 
> mangled exactly the same, so you would have identical symbols 
> in the object file.

The entire point of extern(D, argNames) is that the argument 
names are now included in the mangling.

It would be analogous to how the other extern declaration affect 
mangling (e.g. extern(C) will remove all arguments + types).

> However, one COULD provide a prototype simply for renaming 
> parameters (without implementation). I don't think you even 
> need a specialized extern(D, argNames) marking, if the compiler 
> will just prefer non-deprecated matches over deprecated ones.

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); }
---

Also note that if this would be allowed in the general case the 
following could work:

---
extern(D, argNames):
int sleep(int msecs) { ... }
int sleep(int secs) { sleep(secs*1000); }
sleep(msecs: 200); // OK
sleep(secs: 100); // OK
sleep(1); // ERROR
---

---
extern(D, argNames):
double sin(double rad) { ... }
double sin(double deg) {  }
sin(rad: 0.5); // OK
sin(deg: 90); // OK
sin(0); // ERROR
---

The compiler would need to trigger an ambiguity error if called 
without named arguments.
Anyhow, I'm not interested in this general case.

I just think that it could be a way to make deprecation work 
nicely.