On 8/23/19 3:30 PM, Dennis wrote:
> On Friday, 23 August 2019 at 18:41:56 UTC, H. S. Teoh wrote:
>> I just don't see the benefit of going through all the trouble of the DIP process and subsequent implementation work, only to end
>> up with a half-hearted feature that doesn't even offer these
>> two most desirable things of a named argument implementation.
> 
> The current DIP has less complexity. What if you go through all the trouble of implementing it only to find out some tricky edge cases you didn't think about?

That's exactly why we have a process that replaces seat-of-the-pants language design.

> E.g. what does this code do:
> ```
> import std.stdio;
> void foo(int a, double b) {writeln("0");}
> void foo(int b, int a) {writeln("1");}
> 
> void main()
> {
>      foo(b: 10, 0);
> }
> ```
> 
> You might have an obvious intuition for this situation ("that should be an error!"), but maybe there are other ones.

Good point. This is what the DIP review cycle is for.

On 8/23/19 3:48 PM, Paul Backus wrote:
> On Friday, 23 August 2019 at 19:33:07 UTC, Dennis wrote:
>> Correction:
>> ```
>> import std.stdio;
>> void foo(int a, int b) {writeln("0");}
>> void foo(int b, double a) {writeln("1");}
>> void main()
>> {
>>     foo(b: 10, 0);
>> }
>> ```
>>
>> The point is, is an exact type match more important than parameter order match?
> 
> Walter's proposal from the previous discussion was that named parameters should use the same rules for reordering as named struct initialization [1] (which in turn are the same rules used by designated initializers in C99 [2]). So in this case, the second overload would be called, because it's the only one with a parameter after `b`.
> 
> Even if these aren't your favorite rules, I think there's a lot to be said for consistency.
> 
> [1] https://dlang.org/spec/struct.html#static_struct_init
> [2] http://port70.net/~nsz/c/c99/n1256.html#6.7.8p17

Noice!

On Friday, 23 August 2019 at 19:48:59 UTC, Paul Backus wrote:
> On Friday, 23 August 2019 at 19:33:07 UTC, Dennis wrote:
>
> Walter's proposal from the previous discussion was that named parameters should use the same rules for reordering as named struct initialization [1] (which in turn are the same rules used by designated initializers in C99 [2]). So in this case, the second overload would be called, because it's the only one with a parameter after `b`.
>
> Even if these aren't your favorite rules, I think there's a lot to be said for consistency.
>
> [1] https://dlang.org/spec/struct.html#static_struct_init
> [2] http://port70.net/~nsz/c/c99/n1256.html#6.7.8p17

> struct S { int a, b, c, d = 7; }
> S w = { b:1, 3 };             // v.a = 0, v.b = 1, v.c = 3, v.d = 7

unnamed arg after named is weird/error prone. u should to know right order
(here names are ordered so it not usual case)
imo better forbid named args before unnamed OR unnamed args after named
> unnamed, unnamed, unnamed, named, named, named

On Friday, 23 August 2019 at 19:55:31 UTC, Andrei Alexandrescu wrote:
> On 8/23/19 3:30 PM, Dennis wrote:
>> On Friday, 23 August 2019 at 18:41:56 UTC, H. S. Teoh wrote:
>
>> E.g. what does this code do:
>> ```
>> import std.stdio;
>> void foo(int a, double b) {writeln("0");}
>> void foo(int b, int a) {writeln("1");}
>> 
>> void main()
>> {
>>      foo(b: 10, 0);
>> }
>> ```
>> 
>> You might have an obvious intuition for this situation ("that should be an error!"), but maybe there are other ones.
>
> Good point. This is what the DIP review cycle is for.

does rule "named args after unnamed" solve this problem?
foo( b:10, 0 ); // C# ERROR: Named arguments must appear after the positional arguments

foo( 0, b:10); // foo( int, int) no doubts

On Friday, 23 August 2019 at 15:01:20 UTC, Andrei Alexandrescu wrote:
> On 8/23/19 6:54 AM, Mike Parker wrote:
>> DIP 1019, "Named Arguments Lite", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Átila for the Formal Assessment.
>> 
>> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>> 
>> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>> 
>> The current revision of the DIP for this review is located here:
>> 
>> https://github.com/dlang/DIPs/blob/3bc3469a841b87517a610f696689c8771e74d9e5/DIPs/DIP1019.md
>> 
>> 
>> In it you'll find a link to and summary of the previous review rounds. This round of review will continue until 11:59 pm ET on September 6 unless I call it off before then.
>> 
>> Thanks in advance for your participation.
>
> The DIP is well researched and clearly written. Kudos.
>
> Sadly I oppose it on the following grounds:
>
> "Named arguments proposed by this DIP have no effect on the ordering of arguments in function calls."
>
> "Named arguments proposed by this DIP do not allow default parameters to be skipped."
>
> These two limitations are as useful and help each other as much as a nausea and a cough.
>
> Large parameter lists of which most have reasonable defaults is a marquee use case of named arguments. A proposal that works itself out of that opportunity cannot and should not be acceptable.
>
> I was unconvinced by the argument that these can be added later. Language design is peculiar in that incrementalism doesn't work well - it must come all at once. There are exceptions and arguments that can be made but there's overwhelming evidence that incremental language design is just not a good way to go about things.

To stress these points, IntelliJ IDEA has the possibility to show the function arguments name while reading source code (it isn't implemented for D). Other IDEs maybe provide something similar.

What I want to say: The current scope of the DIP does only hard code what a good IDE is able to provide on the fly.

I really miss the possibility to skip optional parameters.

Kind regards
Andre

On 8/23/2019 3:54 AM, Mike Parker wrote:
> DIP 1019, "Named Arguments Lite", is now ready for Final Review. This is the last chance for community feedback before the DIP is handed off to Walter and Átila for the Formal Assessment.


I reiterate my previous opinion:

https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Community_Review_Round_2_327714.html#N327755

For reference, the previous discussion threads:

Round 1:

https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Community_Review_Round_1_324110.html

Round 2:

https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Community_Review_Round_2_327714.html

On Friday, 23 August 2019 at 17:59:38 UTC, Andrei Alexandrescu wrote:
> On 8/23/19 1:42 PM, H. S. Teoh wrote:
>> On Fri, Aug 23, 2019 at 05:16:16PM +0000, bachmeier via Digitalmars-d wrote:
>>> [...]
>> [...]
>>> [...]
>> [...]
>> 
>> But this:
>> 
>> 	foo(x: 4, y: 8, z: 9,
>> 		screen: scr1, widget: wg2,
>> 		options: opts, menu: menu3);
>> 
>> is no worse than this:
>> 
>> 	FooParams params;
>> 	params.x = 4;
>> 	params.y = 8;
>> 	params.z = 9;
>> 	params.screen = scr1;
>> 	params.widget = wg2;
>> 	params.options = opts;
>> 	params.menu = menu3;
>> 	foo(params);
>
> Exactly. It seems that for short lists (2-3 arguments) naming would be a net negative (add notational overhead when there's little possibility of a confusion to start with).

You don't have to add the names, it's not mandatory.

> Then, when the list gets longer it actually makes matters _worse_ because it disallows skipping of defaulted arguments.

What do you mean by "worse". It's not currently possible to skip default arguments anyways.

There is no way for incorporating this DIP to be a negative.

So, again, there are a lot of suggestions that we need reordering, default arguments skipping, etc. And I completely agree. If someone come forward and write a well thought out named argument DIP with those features, I would happily drop mine.

However, during the 6 months long review of this (and DIP 1020, but that one is in hiatus right now), no one did. People cares a lot about these features, but not enough to write a DIP.

This is my biggest fear, that if we don't adapt this DIP and start iterate on that, D will not have named arguments for the foreseeable future.

Please prove me wrong. Go write a DIP.

On Friday, 23 August 2019 at 16:47:14 UTC, H. S. Teoh wrote:
> On Fri, Aug 23, 2019 at 04:19:51PM +0000, Dennis via Digitalmars-d wrote:
>> > [...]
>
> Exactly the same objections I have against this DIP.  OT1H it's trying to get named arguments into the language, but OTOH it takes out what I would consider to be two of the most important reasons to *have* named arguments: skipping default parameters, and out-of-order argument passing.  Therefore, it essentially nullifies its own raison d'etre.

It DOES NOT prevent them from being added later. Like I have already reiterated multiple times, this is not the be-all and end-all named arguments DIP.

>
>
>> [...]
> [...]
>
> [...]
>
> Furthermore, if this DIP hadn't shot itself in its own foot by not allowing out-of-order argument passing and skipping default parameters, then it would have actually made overly-long parameter lists actually *acceptable*, in the sense that the function could just supply default values for most of the parameters, and the caller can just name and pass the few arguments that it wants to be different from the defaults, and the rest don't have to be explicitly specified.

It does not always make sense to supply default values for parameters.

e.g createWindow(int width, int height)

What default value do you give them?

>
>
> T