tl;dr: `pragma(mangle, withArgumentNames:true)` would be a way to tell the compiler to include the argument names in the ABI, s.t. overloads with different names can be resolved.

Why?

1) Provide implementations for different input formats
------------------------------------------------------

```
sin(deg: 90);
sin(rad: 0.5);
```

2) Allow for a smooth deprecation
---------------------------------


```
deprecated pragma(mangle, withArgumentNames:true) void snoopy(int dummy); // A
void snoopy(int width); // B

snoopy(dummy: 10); // A (-> deprecation message)
snoopy(width: 10); // B
snoopy(10); // B
```

Mangling would be roughly sth. like:

```
_D9app3fooFiQdummyZv // includes argument names
_D9app3fooFiZv // regular
```


This could potentially result in really names with many parameters, but I doubt it would be as bad as a few templated ranges (see e.g. https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/).
However, if long names are a concern, solutions could be:

1) Let the user specify mangling himself, e.g.

```
deprecated pragma(mangle, withArgumentNames:{"dummy": "d"}) void snoopy(int dummy); // A
```

2) Let the user define a custom mangling postfix:

```
deprecated pragma(mangle, postfix:"dummy") void snoopy(int dummy); // A
```

3) Or build a hash of all arguments names.


What are your though on optionally allowing to include argument names into the ABI?

On Thursday, 17 September 2020 at 14:12:13 UTC, Seb wrote:
> tl;dr: `pragma(mangle, withArgumentNames:true)` would be a way to tell the compiler to include the argument names in the ABI, s.t. overloads with different names can be resolved.
>
> [snip]

I don't have an opinion on the options, but I do like the general approach. Concern about depreciations was my only issue with the DIP.

On Thursday, 17 September 2020 at 14:12:13 UTC, Seb wrote:
> tl;dr: `pragma(mangle, withArgumentNames:true)` would be a way to tell the compiler to include the argument names in the ABI, s.t. overloads with different names can be resolved.
>
> Why?
>
> 1) Provide implementations for different input formats
> ------------------------------------------------------
>
> ```
> sin(deg: 90);
> sin(rad: 0.5);
> ```

I think the example provided is not the best argument for this feature. The problem with it is that deg, and rad, should actually be distinctive types. Then you could implement those types to support following syntaxes such as 0.5 * rad or 0.5.rad, for convenience.

Regards,
Alex.

On Thursday, 17 September 2020 at 16:11:08 UTC, Alexandru Ermicioi wrote:
> On Thursday, 17 September 2020 at 14:12:13 UTC, Seb wrote:
>> tl;dr: `pragma(mangle, withArgumentNames:true)` would be a way to tell the compiler to include the argument names in the ABI, s.t. overloads with different names can be resolved.
>>
>> Why?
>>
>> 1) Provide implementations for different input formats
>> ------------------------------------------------------
>>
>> ```
>> sin(deg: 90);
>> sin(rad: 0.5);
>> ```
>
> I think the example provided is not the best argument for this feature. The problem with it is that deg, and rad, should actually be distinctive types. Then you could implement those types to support following syntaxes such as 0.5 * rad or 0.5.rad, for convenience.
>
> Regards,
> Alex.

Yes, but the "feature" is really only intended to be useful for smooth deprecation.
It is just a nice side effects that this works as well.

>  The problem with it is that deg, and rad, should actually be distinctive types.

They aren't in the standard library.

Another example would be `wait(seconds: 5)` or `wait(minutes: 10)`. I'm aware that we have `dur`.
It's just that as deprecations require ABI mangling, it would open up this feature.
If that's not popular, we don't need to allow it. I'm solely interested in `deprecate` for argument names. So this could be restricted to scopes with `deprecate` only.