• Seb (43/43) Sep 17 2020 tl;dr: `pragma(mangle, withArgumentNames:true)` would be a way to
• jmh530 (4/8) Sep 17 2020 I don't have an opinion on the options, but I do like the general
• Alexandru Ermicioi (8/18) Sep 17 2020 I think the example provided is not the best argument for this
• Seb (13/36) Sep 17 2020 Yes, but the "feature" is really only intended to be useful for

Seb <seb wilzba.ch> writes:

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?

jmh530 <john.michael.hall gmail.com> writes:

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.

Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:

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.

Seb <seb wilzba.ch> writes:

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.