On Monday, 26 August 2019 at 22:45:16 UTC, Walter Bright wrote:
> On 8/26/2019 7:47 AM, Kagamin wrote:
>> struct S { int a, b, c, d = 7; }
>> S w = { c:1, a:1, 3 };
>> 
>> I don't even know if this result is contrived. Maybe it's trivial?
>
> It initializes to:
>
>     c = 1
>     a = 1
>     b = 3
>     d = 7

So just to test out what people would say, I went around my team with this (individually, they didn't hear each other)

struct S { int a = 1, b = 2, c = 3, d = 4; }

void main() {
    S w = { d: 9, a: 9, 9 };
    writeln(w);
}

The answers:

1. a 9, d: 9,... b...2? wait no .... what? Ok I don't know.
2. ambiguous? compile error! why would this be allowed?
3. does the last 9 set all the unset vars??
4. Can't tell, but the first highest non set address?
5. compilation error
6. What is this. What is the usefulness of this. Nothing happens. It's bad. It should crash. I hate life.
7. this can't compile. If it does I would assume it's thrown away?
8. should crash?

Please don't allow the same logic to go in to named arguments.

27.08.2019 16:47, aliak пишет:
> On Monday, 26 August 2019 at 22:45:16 UTC, Walter Bright wrote:
> 
> So just to test out what people would say, I went around my team with this (individually, they didn't hear each other)
> 
> struct S { int a = 1, b = 2, c = 3, d = 4; }
> 
> void main() {
>      S w = { d: 9, a: 9, 9 };
>      writeln(w);
> }
> 
> The answers:
> 
> 1. a 9, d: 9,... b...2? wait no .... what? Ok I don't know.
> 2. ambiguous? compile error! why would this be allowed?
> 3. does the last 9 set all the unset vars??
> 4. Can't tell, but the first highest non set address?
> 5. compilation error
> 6. What is this. What is the usefulness of this. Nothing happens. It's bad. It should crash. I hate life.
> 7. this can't compile. If it does I would assume it's thrown away?
> 8. should crash?
> 
> Please don't allow the same logic to go in to named arguments.

That is rather simple logic - named arguments are defined by name, unnamed ones are defined by position starting from the last named argument, i.e. the first unnamed argument follows the last named one.

On Tuesday, 27 August 2019 at 13:47:49 UTC, aliak wrote:
> ...
> struct S { int a = 1, b = 2, c = 3, d = 4; }
>
> void main() {
>     S w = { d: 9, a: 9, 9 };
>     writeln(w);
> }
>
> The answers:
> ...

Looking the snippet I'd expect the result to be: "A", "B" and "D" to be 9, which is the case according the compiler.

> 3. does the last 9 set all the unset vars??

Maybe one thing that might be added for "filling" would be:

S w = { d: 9, a: 9, 9... };   // Note the ellipsis "..."

Matheus.

On Monday, 26 August 2019 at 22:45:16 UTC, Walter Bright wrote:
> On 8/26/2019 7:47 AM, Kagamin wrote:
>> struct S { int a, b, c, d = 7; }
>> S w = { c:1, a:1, 3 };
>> 
>> I don't even know if this result is contrived. Maybe it's trivial?
>
> It initializes to:
>
>     c = 1
>     a = 1
>     b = 3
>     d = 7

I suspect struct initializer is used only in two forms: all named initializers or all positional initializers, so Ada named arguments logic can be used for struct initializer too.

On Tuesday, 27 August 2019 at 05:21:55 UTC, Dukc wrote:
> This all being said, you actually wrote a DIP. It's easy to bash the concept when one has to consider only the concept, not corner cases and specification. I don't agree with Andrei: writing a DIP with argument reordering would be a major undertaking, just as difficult and very possibly more so than this one with all the corner cases to consider. We can't except to easily find a champion for that.

It's not very obvious, but straightforward enough: when evaluating best match for named arguments, match parameters by name instead of position.

On Saturday, 24 August 2019 at 16:36:51 UTC, Andrei Alexandrescu wrote:
> On 8/23/19 6:23 PM, Walter Bright wrote:
>> I reiterate my previous opinion:
>> 
>> https://digitalmars.com/d/archives/digitalmars/D/DIP_1019--Named_Arguments_Lite--Community_Review_Round_2_327714.html#N327755
>
> We have two competing proposals for named arguments. Walter's alternative has been consistently ignored, though I notice Walter mentioned it more than once. That would be totally fine if the proposals were better, but it doesn't take much to figure Walter's is obviously way better, simpler, and integrates beautifully within the existing language.
>
> This entire dynamics strikes me as massively counterproductive. Why are we doing this?

I kinda want to point out that neither you nor Walter have much ground to stand out when it comes to complaining about feedback being ignored.

When Walter posted DIP-1021, I gave feedback with detailed examples in multiple occasions (in PR comments and the review thread), wrote a draft for a DIP that will propose an alternate implementation, and posted a type system discussion when I stalled on a problem. I have yet to see any acknowledgment of that work from Walter (atila gave some feedback, though it was fairly surface-level).

I'm not saying I'm mad about that; but the way you're saying "Walter's proposal is obviously superior. Why didn't the author drop his DIP and make a new one based on Walter's idea instead?" seems a little naive of how the process tends to go.

People usually don't give up on their own ideas to champion someone else's alternative. I don't, you probably don't, and Walter certainly doesn't.

On Monday, 26 August 2019 at 23:36:22 UTC, Jonathan M Davis wrote:
> I get the impression that many people just want to use Flag or named arguments as an excuse to avoid even reading the function's documentation. I agree that it's great if what a function call does is obvious at a glance, but I also think that it's dangerous to assume that you know just by looking at the function call. If you don't actually read the function's documentation, then it's easy to end up making bad assumptions about what it does.
>
> Naming is important and having the function's name be representative of what it does makes it far easier to remember what it's supposed to do, and it does help see what code probably does at a glance when you haven't read the docs yet, but ultimately, you need to read the docs, [...] Once you've actually read the docs and are familiar with what the functions do, then the names serve to remind you rather than inform you, and the need to label everything is far less. But for a lot of arguments, you have the names of the variables being passed anyway, and if anyone really wants to label what a boolean literal is for, they can always use a comment in-place.

I'm mostly neutral on named parameters (they're nice to have), but I'm not sure I agree with the reasoning here.

In theory, it would be nice to always refer to documentation before using a function. In practice, in most of my jobs so far, I have almost never done so except when working with an external library, for good reasons:

- I don't want to use an IDE (Atom's multi-cursor support is a core part of my workflow, among other things), which means I don't have documentation-as-hover-text yet.

- I'm often asked to make a 2-lines change in a 60-lines function, and reading the documentation for each function call is simply not an efficient way to do that. I need to be able to locate the parts relevant to my task quickly, and informative names help me *a lot*.

- For most of the code I work on, the documentation looks like this:

    /**
    *** This method is used to set visible or invisible the HopPoints.
    **/
    void makeHopPointVisible(bool i_hopPointVisible);

eg, it paraphrases what the prototype already says.

Now, documentation is important and valuable, and I do read it when I'm eg rewriting a function. But having code that can be understood at a glance without looking at its source/doc is also valuable, and I think this value far outweighs the moral hazard of occasional bikeshedding or of people skipping documentation.

(the above goes triple for developers with accessibility issues, eg blind devs using text-to-speech to browse code)

On Saturday, 24 August 2019 at 16:36:51 UTC, Andrei Alexandrescu wrote:
> On 8/23/19 6:23 PM, Walter Bright wrote:
>> 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
>
> We have two competing proposals for named arguments. Walter's alternative has been consistently ignored, though I notice Walter mentioned it more than once.

It _has not been_ ignored. But, it is just a feedback, not a DIP. So, due process, it is not to be treated with the same weight as a DIP.

> That would be totally fine if the proposals were better, but it doesn't take much to figure Walter's is obviously way better, simpler, and integrates beautifully within the existing language.

Yes, so please, please write a DIP for that proposal.

>
> This entire dynamics strikes me as massively counterproductive. Why are we doing this?

Yes, why are we doing this?

On Tuesday, 27 August 2019 at 13:52:19 UTC, drug wrote:
> 27.08.2019 16:47, aliak пишет:
>> [...]
>
> That is rather simple logic - named arguments are defined by name, unnamed ones are defined by position starting from the last named argument, i.e. the first unnamed argument follows the last named one.

Correct, but simple logic-wise doesn't mean it's obvious, or intuitive.

On Monday, 26 August 2019 at 21:48:42 UTC, Jonathan M Davis wrote:
> On Monday, August 26, 2019 8:18:21 AM MDT Kagamin via Digitalmars-d wrote:
>> On Saturday, 24 August 2019 at 01:09:48 UTC, Jonathan M Davis
>>
>> wrote:
>> > Personally, I'm against named arguments in general. They make the parameter names part of the API, which adds another set of names that you have to get right up front and which will be bike-shedded to death.
>>
>> Errors in function names happen too.
>
> My point is that adding named arguments results in even more bikeshedding over names. We already have more than enough trouble with that over function names and type names in APIs. I don't want parameter names to be added to that. I don't want to have to care about how good the parameter names are or have to worry about breaking anyone's code when changing a parameter name. And since parameter names have never actually been part of the API in D, existing parameter names were not selected with the idea that they would be used by anyone other than the function itself. For instance, if we had named arguments, all of a sudden, we'd have issues with whether range-based used range, r, or some other name entirely for the range that they're consuming or wrapping. Phobos is not at all consistent about that - and it hasn't needed to be. If we added named arguments, that sort of thing would then matter. I don't want to have to deal with any of that.

I agree this _could_ be a problem. In fact, if you were there during the first community review, you would know I anticipated this objection, by adding the @named attribute.

But, OTOH, there are quite a lot of languages supporting named arguments, and I don't think I ever heard this become a problem for them.

So, yes, theoretically this is a problem; in practice, not so much?

>
> The _only_ use case IMHO where they add any real value is when you have a long parameter list where most of the parameters having default arguments.

Disagree. Oftentimes having the name clarifies a function, so the _reader_ doesn't have to read the document to figure out what a function call does (e.g.

    // width first, or height first?
    createWindow(100, 200);

    // ah
    createWindow(height: 100, width: 200);
)

Remember, code is not written just for the compiler to ingest.

>
> - Jonathan M Davis