On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
> On 3/31/2019 5:33 AM, Mike Parker wrote:
>> [...]
>
> Here's a much simpler proposal, based on the recognition that D already has named parameters:
>
> [...]

This is really great, as there is also a DIP by Sebastian which goes into the same direction as you proposed.
https://github.com/wilzbach/DIPs/blob/3068c4bfff44063ad34825baf8c35906c5ad787c/DIPs/DIP1xxx-sw.md

The DIP is a little bit broader,
S(a:1, b:2) should be usuable at more places too.

Kind regards
Andre

On Sunday, 7 April 2019 at 08:48:44 UTC, Andre Pany wrote:
> On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
>> On 3/31/2019 5:33 AM, Mike Parker wrote:
>>> [...]
>>
>> Here's a much simpler proposal, based on the recognition that D already has named parameters:
>>
>> [...]
>
> This is really great, as there is also a DIP by Sebastian which goes into the same direction as you proposed.
> https://github.com/wilzbach/DIPs/blob/3068c4bfff44063ad34825baf8c35906c5ad787c/DIPs/DIP1xxx-sw.md
>
> The DIP is a little bit broader,
> S(a:1, b:2) should be usuable at more places too.
>
> Kind regards
> Andre

Walter's idea correctly handles default arguments unlike the DIP you linked.

On Sunday, 7 April 2019 at 08:58:36 UTC, Daniel N wrote:
> On Sunday, 7 April 2019 at 08:48:44 UTC, Andre Pany wrote:
>> On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
>>> On 3/31/2019 5:33 AM, Mike Parker wrote:
>>>> [...]
>>>
>>> Here's a much simpler proposal, based on the recognition that D already has named parameters:
>>>
>>> [...]
>>
>> This is really great, as there is also a DIP by Sebastian which goes into the same direction as you proposed.
>> https://github.com/wilzbach/DIPs/blob/3068c4bfff44063ad34825baf8c35906c5ad787c/DIPs/DIP1xxx-sw.md
>>
>> The DIP is a little bit broader,
>> S(a:1, b:2) should be usuable at more places too.
>>
>> Kind regards
>> Andre
>
> Walter's idea correctly handles default arguments unlike the DIP you linked.

I would not call this an idea. This is rather an evidence based on observation of the nature...

I don't care personally about the feature but what does really worry me is that things like `@named` or any other syntactic changes tend to turn D into an incoherent language.

The problem is that someone needs to write the correct proposal. IIRC Bright is not pro named argument and he said that he needs a solid DIP to be convinced.

On Sunday, 7 April 2019 at 10:00:04 UTC, AltFunction1 wrote:
>
> I don't care personally about the feature but what does really worry me is that things like `@named` or any other syntactic changes tend to turn D into an incoherent language.
>

The day that named arguments has to have a special syntax in the function definition is the day I will quit using D tbh.

On Sunday, 7 April 2019 at 12:35:34 UTC, bauss wrote:
> On Sunday, 7 April 2019 at 10:00:04 UTC, AltFunction1 wrote:
>>
>> I don't care personally about the feature but what does really worry me is that things like `@named` or any other syntactic changes tend to turn D into an incoherent language.
>>
>
> The day that named arguments has to have a special syntax in the function definition is the day I will quit using D tbh.

Well, walter is on the same page.

Walter:
"I don't see much point in requiring the names, preventing use of names, nor aliasing them. This has never been an issue for struct initializers."

So you probably don't have to worry about that.

On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
> On 3/31/2019 5:33 AM, Mike Parker wrote:
>> [...]
>
> Here's a much simpler proposal, based on the recognition that D already has named parameters:
>
> [...]

I thought people don't like opt-ins. Yet this DIP, your proposal, and several other proposals in this thread are all opt-in.

Am I allowed to include the @named attribute in my DIP now? :)

On Sunday, 7 April 2019 at 13:48:09 UTC, Yuxuan Shui wrote:
> On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
>> On 3/31/2019 5:33 AM, Mike Parker wrote:
>>> [...]
>>
>> Here's a much simpler proposal, based on the recognition that D already has named parameters:
>>
>> [...]
>
> I thought people don't like opt-ins. Yet this DIP, your proposal, and several other proposals in this thread are all opt-in.
>
> Am I allowed to include the @named attribute in my DIP now? :)

Walter's proposal isn't opt-in. The declarations of `snoopy` in his example are just regular D function declarations; there's nothing special added to them to enable the use of named arguments.

This is, I think, conclusive evidence against the proposition that "W&A will only accept an extremely conservative, opt-in version of named arguments." So any further defense of syntax like DIP 1019's @named or DIP 1020's angle brackets will have to be based on their actual merits, rather than on the mistaken idea that they will make a DIP more likely to be accepted.

On 4/7/19 10:25 AM, Paul Backus wrote:
> On Sunday, 7 April 2019 at 13:48:09 UTC, Yuxuan Shui wrote:
>> On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
>>> On 3/31/2019 5:33 AM, Mike Parker wrote:
>>>> [...]
>>>
>>> Here's a much simpler proposal, based on the recognition that D already has named parameters:
>>>
>>> [...]
>>
>> I thought people don't like opt-ins. Yet this DIP, your proposal, and several other proposals in this thread are all opt-in.
>>
>> Am I allowed to include the @named attribute in my DIP now? :)
> 
> Walter's proposal isn't opt-in. The declarations of `snoopy` in his example are just regular D function declarations; there's nothing special added to them to enable the use of named arguments.
> 
> This is, I think, conclusive evidence against the proposition that "W&A will only accept an extremely conservative, opt-in version of named arguments." So any further defense of syntax like DIP 1019's @named or DIP 1020's angle brackets will have to be based on their actual merits, rather than on the mistaken idea that they will make a DIP more likely to be accepted.

Indeed. Probably a more accurate way to put it is "W&A will only accept /good/ ideas for named arguments (or anything else really)", which, however, is too general to be informative.

Walter's idea is in the same category as the "a line of code where most others would need one hundred" I was alluding to.

It is, in fact, so simple it's liable to be misunderstood. "This can't be so simple, there's got to be some opt-in trick somewhere".

On Sunday, 7 April 2019 at 14:25:43 UTC, Paul Backus wrote:
> On Sunday, 7 April 2019 at 13:48:09 UTC, Yuxuan Shui wrote:
>> On Sunday, 7 April 2019 at 03:09:23 UTC, Walter Bright wrote:
>>> On 3/31/2019 5:33 AM, Mike Parker wrote:
>>>> [...]
>>>
>>> Here's a much simpler proposal, based on the recognition that D already has named parameters:
>>>
>>> [...]
>>
>> I thought people don't like opt-ins. Yet this DIP, your proposal, and several other proposals in this thread are all opt-in.
>>
>> Am I allowed to include the @named attribute in my DIP now? :)
>
> Walter's proposal isn't opt-in. The declarations of `snoopy` in his example are just regular D function declarations; there's nothing special added to them to enable the use of named arguments.
>
Yeah. Sorry, I misread the proposal.

The only problem I can see for now is that this proposal seems to mandate the inclusion of parameter names in mangled name of functions. Which makes name changes not only API breakages, but also ABI breakages.

On 4/7/2019 10:14 AM, Yuxuan Shui wrote:
> this proposal seems to mandate the inclusion of parameter names in mangled name of functions.

Nope.