On Monday, 8 April 2019 at 23:09:31 UTC, bauss wrote:
> On Monday, 8 April 2019 at 16:33:36 UTC, Yuxuan Shui wrote:
>> The interpretation of his proposal suggested by you (i.e. this call is ambiguous) is obviously a possible one, but not necessarily what Walter intended.
>
> And in that case it doesn't matter really because it's not a situation that would ever happen.

Even if 'D' somehow defined that this is valid D code:

void x(int p1) {}
void x(int p2) {}

Some linkers would refuse to link it (including our own OPTLINK and the MS linker), since D has to support a great number of different linkers, we cannot mandate that all linkers in the world need to have a special force flag to override and link anyway just to be compatible with the above construct.

For that reason I don't think Walters comment is open for interpretation, the above program is ill-formed.

Even if, for compilation speed optimization reasons, the compiler might not be required to issue a diagnostic, it still doesn't change the fact that the program is ill-formed, another conforming D compiler should be allowed to reject that code.

On Tuesday, 9 April 2019 at 07:21:33 UTC, Daniel N wrote:
> On Monday, 8 April 2019 at 23:09:31 UTC, bauss wrote:
>> On Monday, 8 April 2019 at 16:33:36 UTC, Yuxuan Shui wrote:
>>> The interpretation of his proposal suggested by you (i.e. this call is ambiguous) is obviously a possible one, but not necessarily what Walter intended.
>>
>> And in that case it doesn't matter really because it's not a situation that would ever happen.
>
> Even if 'D' somehow defined that this is valid D code:
>
> void x(int p1) {}
> void x(int p2) {}
>
> Some linkers would refuse to link it (including our own OPTLINK and the MS linker), since D has to support a great number of different linkers, we cannot mandate that all linkers in the world need to have a special force flag to override and link anyway just to be compatible with the above construct.
>
> For that reason I don't think Walters comment is open for interpretation, the above program is ill-formed.
>
> Even if, for compilation speed optimization reasons, the compiler might not be required to issue a diagnostic, it still doesn't change the fact that the program is ill-formed, another conforming D compiler should be allowed to reject that code.

It's not valid D code when you try to call them, which is why it won't matter.

On 09/04/2019 7:21 PM, Daniel N wrote:
> On Monday, 8 April 2019 at 23:09:31 UTC, bauss wrote:
>> On Monday, 8 April 2019 at 16:33:36 UTC, Yuxuan Shui wrote:
>>> The interpretation of his proposal suggested by you (i.e. this call is ambiguous) is obviously a possible one, but not necessarily what Walter intended.
>>
>> And in that case it doesn't matter really because it's not a situation that would ever happen.
> 
> Even if 'D' somehow defined that this is valid D code:
> 
> void x(int p1) {}
> void x(int p2) {}
> 
> Some linkers would refuse to link it (including our own OPTLINK and the MS linker), since D has to support a great number of different linkers, we cannot mandate that all linkers in the world need to have a special force flag to override and link anyway just to be compatible with the above construct.
> 
> For that reason I don't think Walters comment is open for interpretation, the above program is ill-formed.
> 
> Even if, for compilation speed optimization reasons, the compiler might not be required to issue a diagnostic, it still doesn't change the fact that the program is ill-formed, another conforming D compiler should be allowed to reject that code.

In DIP 1020 I did not want or allowed named parameters to affect name mangling or lookup. Its a very simple solution, but it solves so many problems.

On Monday, 1 April 2019 at 11:39:50 UTC, rikki cattermole wrote:
> As the author of this DIP, I have created a list of actionable items I expect to include in the next iteration of the DIP.
>
> [...]

BTW are you aware of the recently accepted PEP 570 for Python [1]?

It allows library authors optionally to control exactly which parameters are positional and which are keyword-only and which are both.

[1] https://www.python.org/dev/peps/pep-0570/

On Tuesday, 9 April 2019 at 19:46:47 UTC, Seb wrote:
> On Monday, 1 April 2019 at 11:39:50 UTC, rikki cattermole wrote:
>> As the author of this DIP, I have created a list of actionable items I expect to include in the next iteration of the DIP.
>>
>> [...]
>
> BTW are you aware of the recently accepted PEP 570 for Python [1]?
>
> It allows library authors optionally to control exactly which parameters are positional and which are keyword-only and which are both.
>
> [1] https://www.python.org/dev/peps/pep-0570/

Can't say I'm a fan of the chosen syntax (also can't say I can think of anything better in python's case). But IMO they've got the motivation, rationale, and benefits down awesomely well. It's finally fixing (in theory) one of my personal sore points with python :D

It's worth considering allowing API authors to control how their APIs ought to be called. I've never completely understood why reordering is a requirement for some from the caller's side. It doesn't really add anything in terms of readability or maintainability in my experience - in-fact it reduces them because consistency goes out the window. And I'm not sure how allowing all parameters to be called as named is going to help in anyway other than making API authors' lives harder in terms of maintenance costs:

On 10/04/2019 7:46 AM, Seb wrote:
> On Monday, 1 April 2019 at 11:39:50 UTC, rikki cattermole wrote:
>> As the author of this DIP, I have created a list of actionable items I expect to include in the next iteration of the DIP.
>>
>> [...]
> 
> BTW are you aware of the recently accepted PEP 570 for Python [1]?
> 
> It allows library authors optionally to control exactly which parameters are positional and which are keyword-only and which are both.
> 
> [1] https://www.python.org/dev/peps/pep-0570/

Its basically partial reordering as I described in this DIP.

So yay one more reference!

On Tuesday, 9 April 2019 at 19:46:47 UTC, Seb wrote:
> On Monday, 1 April 2019 at 11:39:50 UTC, rikki cattermole wrote:
>> As the author of this DIP, I have created a list of actionable items I expect to include in the next iteration of the DIP.
>>
>> [...]
>
> BTW are you aware of the recently accepted PEP 570 for Python [1]?
>
> It allows library authors optionally to control exactly which parameters are positional and which are keyword-only and which are both.
>
> [1] https://www.python.org/dev/peps/pep-0570/

Wow, that syntax looks bad. I like Dart's syntax for that:

void enableFlags([bool foo]) {...} <- positional arg
void enableFlags({bool foo}) {...} <- keyword arg
void enableFlags({@required bool foo}) {...} <- required keyword arg

On 4/9/19 5:20 PM, aliak wrote:
> It's worth considering allowing API authors to control how their APIs ought to be called. I've never completely understood why reordering is a requirement for some from the caller's side. It doesn't really add anything in terms of readability or maintainability in my experience - in-fact it reduces them because consistency goes out the window. And I'm not sure how allowing all parameters to be called as named is going to help in anyway other than making API authors' lives harder in terms of maintenance costs:
> 

If you have named arguments, and allow skipping over optional arguments, but *don't* allow reordering, you end up with some really silly-looking errors:

// One of these calls will fail to compile spawnProcess("./do_stuff", stdout: outputFile, stderr: logFile);

// This doesn't, because 'stdout' comes before 'stderr' spawnProcess("./do_stuff", stderr: logFile, stdout: outputFile);

Would you rather (a) have to explain to new D users why the first one
works and the second one doesn't, or (b) live with parameter reordering
being allowed?

On Wednesday, 10 April 2019 at 17:13:04 UTC, Paul Backus wrote:
> On 4/9/19 5:20 PM, aliak wrote:
>> It's worth considering allowing API authors to control how their APIs ought to be called. I've never completely understood why reordering is a requirement for some from the caller's side. It doesn't really add anything in terms of readability or maintainability in my experience - in-fact it reduces them because consistency goes out the window. And I'm not sure how allowing all parameters to be called as named is going to help in anyway other than making API authors' lives harder in terms of maintenance costs:
>> 
>
> If you have named arguments, and allow skipping over optional arguments, but *don't* allow reordering, you end up with some really silly-looking errors:
>
> // One of these calls will fail to compile spawnProcess("./do_stuff", stdout: outputFile, stderr: logFile);
>
> // This doesn't, because 'stdout' comes before 'stderr' spawnProcess("./do_stuff", stderr: logFile, stdout: outputFile);
>
> Would you rather (a) have to explain to new D users why the first one
> works and the second one doesn't, or (b) live with parameter reordering
> being allowed?

Most definitely a :) For a few reasons.

1) Semantic meaning: the semantic meaning that is present in the order of parameters matters in APIs (not always, but often enough). I.e. with algorithms in c++, the call sites would make you look twice and go "huh" if _end_ was passed before _begin_. So mentally, having to parse all these becomes a harder task:

generate!int(start: 0, end: 10, stride: 2) vs
generate!int(stride: 2, end: 10, start: 0) vs
generate!int(end: 10, stride: 2, start: 0) vs

2) Learnability: Having fixed pos parameters is easier to learn because you consistently repeat the same pattern

3) Reduced mental anguish :p - ok I'm being a bit dramatic here and I have no data to back this up, but if I saw this:

auto c = color(g=123, b=2, a=3, r=7)

I personally, and I'm pretty sure I'd bet monies that any - or most - graphics engineers, would die just a weeeee little bit.

4) Consistency: allowing all the possible permutations of a function would just lead to inconsistent call sites. Consistent is usually better than inconsistent in any large code base.

5) Searchability: searching is possible - grepping or ctrl+f "function(firstName:" has helped me out *many* times. You could not rely on this if re-ordering is allowed.

6) What's so complicated about the explanation: "yeah you have to specify the arguments in order they're declared"? I've been using objective-c and then swift for the past 7 years now, and I haven't been confronted with the any kind of negativity associated to not being able to reorder arguments.

Also: if named arguments are reorderable and optional, should we worry about this scenario - i'm not sure we should but just throwing out there as a thought:

// User A writes code
move(y=0, x=1)
// User B comes at some point and decides variable names are good enough
move(y, x)

// and the actual function declaration is:
move(int x, int y)

For the record, I could live with either - but I have a preference for positional. I don't see the advantage of reordering though. Is it just to avoid not having to tell people that you need to specify arguments in the order they're declared? Is it because it's easier to write out the function call? Are there some technical advantages? Is it (much) easier to implement?

Cheers,
- Ali

On 4/9/2019 12:46 PM, Seb wrote:
> It allows library authors optionally to control exactly which parameters are positional and which are keyword-only and which are both.
> 
> [1] https://www.python.org/dev/peps/pep-0570/

Note that there is a way to require positional-only in D:

    int foo(int);

I.e. leave off the parameter name.

It works when there's a separate .di file from the implementation .d file (which would have the names). It won't work for template parameters.

As for renaming parameters,

    void foo(T oldname);

becomes:

    void foo(T)(T oldname) { return foo(newname : oldname); }
    void foo(T newname);

Yeah, it's a little awkward, but if you're renaming parameters you've got awkward backwards compatibility issues anyway.