On Friday, 24 July 2015 at 19:59:17 UTC, Shammah Chancellor wrote:
> On Friday, 24 July 2015 at 19:45:55 UTC, Jonathan M Davis wrote:
>> On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor wrote:
>>> Since D has optional arguments -- why don't we support named parameters?  There are extremely handy and work beautifully in languages like C#.
>>
>> We've argued about this several times in the past. We're not adding them. They interact badly with overloading (especially if you try and add more overloads later), and they make it so that the parameter names are part of the API, which means even more bikeshedding and arguments about naming.
>>
>> - Jonathan M Davis
>
> Funny, they work beautifully in C#.
>
> https://msdn.microsoft.com/en-us/library/dd264739.aspx

The example presented in there would benefit from extra typing rather that named argument. D provide this, but C# doesn't as far as I know.

Am Fri, 24 Jul 2015 14:04:17 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 7/24/2015 10:15 AM, tcak wrote:
> > How would this create a problem I can't see.
> 
> The question is what problem does it solve.

At least:
1 Better readable code with literal parameters
  auto x = window.addNewControl("Title", 20, 50, 100, 50, true);
  There are some domains which would benefit a lot from this (every
  OpenGL function call, most graphics/image libraries)

2 If you have many parameters with default values, you can keep default
  values for all other parameters and overwrite only one. This can
  sometimes be done with overloads, but what if you've got parameters
  of the same type:
  void foo(bool a = function1(x, y), bool b = function2(x, y), bool c =
      function1(x, y))
  foo(function1(x, y), function2(x, y), false); => foo(c = false)

3 One thing that's sometimes annoying in D is that it's not possible to
  have normal arguments after a variadic argument. Named parameters
  could solve that:
  void foo(A, T... args, B) => foo!(int, int, bool, B = bool)


Note that there are languages which allow named parameters but do not allow parameter reordering. This still allows 1 and 3 but the implementation is simpler.

On 2015-07-24 23:04, Walter Bright wrote:

> The question is what problem does it solve.

For one thing, it avoids the ugly hack which is the Flag template and Yes/No structs.

With Flag:

string getLine(Flag!"keepTerminator" keepTerminator);
getLine(Flag!"keepTerminator".yes);

With named parameters:

string getLine(bool keepTerminator);
getLine(keepTerminator: true);

-- 
/Jacob Carlborg

On Saturday, 25 July 2015 at 09:41:19 UTC, Jacob Carlborg wrote:
> On 2015-07-24 23:04, Walter Bright wrote:
>
>> The question is what problem does it solve.
>
> For one thing, it avoids the ugly hack which is the Flag template and Yes/No structs.
>
> With Flag:
>
> string getLine(Flag!"keepTerminator" keepTerminator);
> getLine(Flag!"keepTerminator".yes);
>
> With named parameters:
>
> string getLine(bool keepTerminator);
> getLine(keepTerminator: true);

If Andrei weren't insisting that we use that idiom everywhere in Phobos, I'd honestly just be using bools and be done with it. It adds some value, but I seriously question that it's worth the extra verbosity. But regardless, I'd hate to see named arguments get added to the language just to clean that mess up.

- Jonathan M Davis

On Saturday, 25 July 2015 at 09:41:19 UTC, Jacob Carlborg wrote:
> On 2015-07-24 23:04, Walter Bright wrote:
>
>> The question is what problem does it solve.
>
> For one thing, it avoids the ugly hack which is the Flag template and Yes/No structs.
>
> With Flag:
>
> string getLine(Flag!"keepTerminator" keepTerminator);
> getLine(Flag!"keepTerminator".yes);
>
> With named parameters:
>
> string getLine(bool keepTerminator);
> getLine(keepTerminator: true);

When showing code don't purposefully make it verbose to strengthen your case. Here is how Flag is usually used:

  getLine(Yes.keepTerminator);

Which is way more readable. Named parameters are not needed!

On Friday, 24 July 2015 at 14:15:11 UTC, Shammah Chancellor wrote:
> Since D has optional arguments -- why don't we support named parameters?  There are extremely handy and work beautifully in languages like C#.

1. This isn't C#
2. I'm sure a template solution would work just fine. I've seen many on these forums.

On Saturday, 25 July 2015 at 11:11:30 UTC, Gary Willoughby wrote:
> 2. I'm sure a template solution would work just fine. I've seen many on these forums.

Here's one:
https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135

On Saturday, 25 July 2015 at 11:14:39 UTC, Gary Willoughby wrote:
> On Saturday, 25 July 2015 at 11:11:30 UTC, Gary Willoughby wrote:
>> 2. I'm sure a template solution would work just fine. I've seen many on these forums.
>
> Here's one:
> https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135

Some more:
http://forum.dlang.org/thread/wokfqqbexazcguffwiif@forum.dlang.org

On 7/25/15 5:41 AM, Jacob Carlborg wrote:
> On 2015-07-24 23:04, Walter Bright wrote:
>
>> The question is what problem does it solve.
>
> For one thing, it avoids the ugly hack which is the Flag template and
> Yes/No structs.
>
> With Flag:
>
> string getLine(Flag!"keepTerminator" keepTerminator);
> getLine(Flag!"keepTerminator".yes);

Replace the second with:

getLine(Yes.keepTerminator);


Andrei

On 7/25/15 6:32 AM, Jonathan M Davis wrote:
> On Saturday, 25 July 2015 at 09:41:19 UTC, Jacob Carlborg wrote:
>> On 2015-07-24 23:04, Walter Bright wrote:
>>
>>> The question is what problem does it solve.
>>
>> For one thing, it avoids the ugly hack which is the Flag template and
>> Yes/No structs.
>>
>> With Flag:
>>
>> string getLine(Flag!"keepTerminator" keepTerminator);
>> getLine(Flag!"keepTerminator".yes);
>>
>> With named parameters:
>>
>> string getLine(bool keepTerminator);
>> getLine(keepTerminator: true);
>
> If Andrei weren't insisting that we use that idiom everywhere in Phobos,
> I'd honestly just be using bools and be done with it. It adds some
> value, but I seriously question that it's worth the extra verbosity. But
> regardless, I'd hate to see named arguments get added to the language
> just to clean that mess up.

Honest I didn't insist, and am a bit surprised that it did catch up. -- Andrei