On Friday, 1 March 2019 at 00:49:25 UTC, Rubn wrote:
> I don't agree with this at all. The feature becomes all but useless, it's either all in or just don't include it. So many things are already part of the API, and this will be an opt-in feature for the user (not the library developer). The user can choose to use the variable names if they want, knowing full well if the author pleases they can change it, but this will be no different than changing the variable name of struct.

It's not comparable to changing the variable name of a struct, because if that struct is a public data structure in a library, changing its field names is a breaking change.  Downstream users should be able to rely on a library maintainer not doing that except in a major release (and even then, providing a clear heads-up and transition path; it might work in some cases to e.g. rename the struct field but add a `deprecated alias oldName = newName`, and then drop that alias only in the next major release).

If the language design is changed so that downstream users _can_ use named arguments, then library maintainers have to assume that they _will_, and treat parameter names accordingly.  It's no good just saying "I don't support this", because if you can't enforce such a constraint ahead of time, you are on a hiding to nothing.

If API opt-in to named parameter support is not adequate, then it's better to drop the feature request entirely, because it is not reasonable to impose a big new responsibility like named arguments on maintainers of existing codebases.

On Sunday, 3 March 2019 at 10:50:05 UTC, Joseph Rushton Wakeling wrote:
> If API opt-in to named parameter support is not adequate, then it's better to drop the feature request entirely, because it is not reasonable to impose a big new responsibility like named arguments on maintainers of existing codebases.

I think you're overstating how big the responsibility is.

Maintainers can still change argument names with the current DIP, they just need to keep exporting a prototype with the old names.

On Sunday, 3 March 2019 at 12:46:22 UTC, Olivier FAURE wrote:
> Maintainers can still change argument names with the current DIP, they just need to keep exporting a prototype with the old names.

Well, since the current DIP is entirely opt-in from the function author side anyway, it's a bit of a moot point. I was responding rather to someone who was arguing that it should _not_ be opt in for function authors.

On Sunday, 3 March 2019 at 10:50:05 UTC, Joseph Rushton Wakeling wrote:
> On Friday, 1 March 2019 at 00:49:25 UTC, Rubn wrote:
>> I don't agree with this at all. The feature becomes all but useless, it's either all in or just don't include it. So many things are already part of the API, and this will be an opt-in feature for the user (not the library developer). The user can choose to use the variable names if they want, knowing full well if the author pleases they can change it, but this will be no different than changing the variable name of struct.
>
> It's not comparable to changing the variable name of a struct, because if that struct is a public data structure in a library, changing its field names is a breaking change.  Downstream users should be able to rely on a library maintainer not doing that except in a major release (and even then, providing a clear heads-up and transition path; it might work in some cases to e.g. rename the struct field but add a `deprecated alias oldName = newName`, and then drop that alias only in the next major release).
>
> If the language design is changed so that downstream users _can_ use named arguments, then library maintainers have to assume that they _will_, and treat parameter names accordingly.
>  It's no good just saying "I don't support this", because if you can't enforce such a constraint ahead of time, you are on a hiding to nothing.
>
> If API opt-in to named parameter support is not adequate, then it's better to drop the feature request entirely, because it is not reasonable to impose a big new responsibility like named arguments on maintainers of existing codebases.

Agree completely. Finally someone arguing from this side :)

On Friday, 1 March 2019 at 13:37:24 UTC, Joseph Rushton Wakeling wrote:
> On Thursday, 28 February 2019 at 21:55:50 UTC, Olivier FAURE wrote:
>> [...]
>
> Is the idea here that you can effectively define "aliases" for the parameter names (e.g. to help transitions), but not have multiple function implementations with the same type signatures and different names?
>
> That presumably impacts back on the mangling question, and whether the parameter names need to be included in the function mangling ... ?

Function names won't be included in mangling. It is a bit complicated now since this version of this DIP includes reordering, but the next revision won't.

On Sunday, 3 March 2019 at 09:36:32 UTC, Joseph Rushton Wakeling wrote:
>
> Note that this would be simpler from a developer point of view if it was possible to declare "anonymous" structs in place in the function declarations, i.e.:
>
>     int foo (struct { int w = 10; int h = 10; });
>     int bar (struct { int w = 20; int h = 20; });
>
> ... which combined with the earlier suggestion would also be a fairly natural extension of existing struct syntax.

I think this approach gives every parameter a default value, and thus make them all optional. Which is not necessarily desirable.

On Monday, 4 March 2019 at 12:00:54 UTC, Yuxuan Shui wrote:
> I think this approach gives every parameter a default value, and thus make them all optional. Which is not necessarily desirable.

Agreed.  It was an example of how to solve (essentially within current D idioms) a particular subset of the problems where named arguments are useful.

On Sunday, 3 March 2019 at 15:07:04 UTC, Joseph Rushton Wakeling wrote:
> Well, since the current DIP is entirely opt-in from the function author side anyway, it's a bit of a moot point. I was responding rather to someone who was arguing that it should _not_ be opt in for function authors.

My point was, the DIP should be opt-out, because even then library maintainers can always change argument names if they want to, without breaking code. And even if code does break, it's an extremely easy fix (as in, "change a few names until it compiles", not "refactor everything").

Like, okay, I get that some people are opposed to the very idea of parameter names being important information to keep track of, but pragmatically, the costs of making named arguments the default are far outweighed by the benefits.

On Mon, Mar 04, 2019 at 06:57:16PM +0000, Olivier FAURE via Digitalmars-d wrote:
> On Sunday, 3 March 2019 at 15:07:04 UTC, Joseph Rushton Wakeling wrote:
> > Well, since the current DIP is entirely opt-in from the function author side anyway, it's a bit of a moot point. I was responding rather to someone who was arguing that it should _not_ be opt in for function authors.
> 
> My point was, the DIP should be opt-out, because even then library maintainers can always change argument names if they want to, without breaking code. And even if code does break, it's an extremely easy fix (as in, "change a few names until it compiles", not "refactor everything").
> 
> Like, okay, I get that some people are opposed to the very idea of parameter names being important information to keep track of, but pragmatically, the costs of making named arguments the default are far outweighed by the benefits.

IMNSHO, even if parameter names aren't important information to keep track of, being forced to accomodate renamings would motivate people to actually invent useful, self-explanatory parameter names rather than `func(int a, int b, int c)` or worse, `func(int, int, int)`, with no indication as to what the parameter is supposed to mean.


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan

On Sunday, 17 February 2019 at 21:04:23 UTC, Yuxuan Shui wrote:
> After thinking about the feedback so far, I currently plan to make these changes to this DIP:
>
> ...

Would you also be able to confirm how this DIP handles default arguments and templates?
I think the DIP could use an example showing this off.

One of my almost dally 'is there no better way?' moments with D currently is default template arguments, for example to change throwErrors currently I need to do:

---

T toString(T=string, bool SomeThing=true, bool throwErrors=true, S)(S value){return "";}

auto foo = 123.toString!(string, true, false);

---

Where as I think something like this would be better:

---

auto foo = 123.toString!(throwErrors: false);

---