On Mon, 13 Oct 2014 16:08:07 +0000
ponce via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Work-around I see a lot in C++:
> 
> ---------------
> 
> bool filled = true;
> drawCircle(filled);
> 
> ---------------
> 
> instead of:
> 
> ---------------
> 
> drawCircle(true);
> 
> ---------------

it's not the same, i thing. for this we have Flag in std.typecons, for example.

On 10/13/2014 7:23 AM, Ary Borenszweig wrote:
> On 10/13/14, 5:47 AM, Walter Bright wrote:
>> On 10/13/2014 1:29 AM, "岩倉 澪" wrote:
>>> Are there good reasons not to add something like this to the language,
>>> or is it
>>> simply a matter of doing the work? Has it been discussed much?
>>
>> Named parameters interact badly with overloading.
>
> Could you give an example?

Nothing requires function overloads to use the same names in the same order for parameters. "color" can be the name for parameter 1 in one overload and for parameter 3 in another and not be there at all for a third.

Parameters need not be named in D:

   int foo(long);
   int foo(ulong x);

Named parameters are often desired so that default arguments need not be in order at the end:

   int foo(int x = 5, int y);
   int foo(int y, int z);

To deal with all this, a number of arbitrary rules will have to be created. Overloading is already fairly complex, with the implemented notions of partial ordering. Even if this could all be settled, is it worth it? Can anyone write a document explaining this to people? Do people really want pages and pages of specification for this?

On Monday, 13 October 2014 at 19:18:39 UTC, Walter Bright wrote:
> Nothing requires function overloads to use the same names in the same order for parameters. "color" can be the name for parameter 1 in one overload and for parameter 3 in another and not be there at all for a third.
>
> Parameters need not be named in D:
>
>    int foo(long);
>    int foo(ulong x);
>
> Named parameters are often desired so that default arguments need not be in order at the end:
>
>    int foo(int x = 5, int y);
>    int foo(int y, int z);
>
> To deal with all this, a number of arbitrary rules will have to be created. Overloading is already fairly complex, with the implemented notions of partial ordering. Even if this could all be settled, is it worth it? Can anyone write a document explaining this to people? Do people really want pages and pages of specification for this?

If you have several functions that take optional arguments, like the following:

int foo(bool b = false, int n, float f = 0.0f);
int foo(float n, bool b = false, float f = 0.0f);

foo(2, b: true);
foo(3.0f, f: 1.0f);

Wouldn't it only be necessary to overload on the non-optional arguments? Extending this, if a functional has only optional arguments, then there can only be one version of it.

int foo(int n = 0, bool b = false, float f = 0.0f);
//Error: cannot overload two functions with no non-optional parameters.
int foo(float n = 0.0f, bool b = false, float f = 0.0f);

On Monday, 13 October 2014 at 19:18:39 UTC, Walter Bright wrote:
> On 10/13/2014 7:23 AM, Ary Borenszweig wrote:
>> On 10/13/14, 5:47 AM, Walter Bright wrote:
>>> On 10/13/2014 1:29 AM, "岩倉 澪" wrote:
>>>> Are there good reasons not to add something like this to the language,
>>>> or is it
>>>> simply a matter of doing the work? Has it been discussed much?
>>>
>>> Named parameters interact badly with overloading.
>>
>> Could you give an example?
>
> Nothing requires function overloads to use the same names in the same order for parameters. "color" can be the name for parameter 1 in one overload and for parameter 3 in another and not be there at all for a third.
>
> Parameters need not be named in D:
>
>    int foo(long);
>    int foo(ulong x);
>
> Named parameters are often desired so that default arguments need not be in order at the end:
>
>    int foo(int x = 5, int y);
>    int foo(int y, int z);
>
> To deal with all this, a number of arbitrary rules will have to be created. Overloading is already fairly complex, with the implemented notions of partial ordering. Even if this could all be settled, is it worth it? Can anyone write a document explaining this to people? Do people really want pages and pages of specification for this?

The only thing I like named parameters for is to avoid the following

foo(5 /* count */, true /* enableSpecialFunctionality */)

I like the documentation, but comments in the middle does feel cumbersome.  Tooling could add that automatically of course.  The C# syntax is slightly better:

foo(count: 5, enableSpecialFunctionality: true)

I don't care for or need the ability to reorder parameters, nor do I want additional rules to remember vis-a-vis overloading and optional parameters.  And I don't want a trivial name change in parameters to break my code - functions already have complete signatures, enforcing names just adds one more thing which could break people for no real benefit.

Sometimes I think features are proposed for the language which more rightly belong in tooling.

On 2014-10-13 19:18:38 +0000, Walter Bright said:

> On 10/13/2014 7:23 AM, Ary Borenszweig wrote:
>> On 10/13/14, 5:47 AM, Walter Bright wrote:
>>> On 10/13/2014 1:29 AM, "岩倉 澪" wrote:
>>>> Are there good reasons not to add something like this to the language,
>>>> or is it
>>>> simply a matter of doing the work? Has it been discussed much?
>>> 
>>> Named parameters interact badly with overloading.
>> 
>> Could you give an example?
> 
> Nothing requires function overloads to use the same names in the same order for parameters. "color" can be the name for parameter 1 in one overload and for parameter 3 in another and not be there at all for a third.
> 
> Parameters need not be named in D:
> 
>     int foo(long);
>     int foo(ulong x);
> 
> Named parameters are often desired so that default arguments need not be in order at the end:
> 
>     int foo(int x = 5, int y);
>     int foo(int y, int z);
> 
> To deal with all this, a number of arbitrary rules will have to be created. Overloading is already fairly complex, with the implemented notions of partial ordering. Even if this could all be settled, is it worth it? Can anyone write a document explaining this to people? Do people really want pages and pages of specification for this?

Not to mention, that despite C# supporting this, MSFT's code analysis generates a warning and instead recommends providing more overloads.

-S.

On Monday, 13 October 2014 at 08:29:42 UTC, 岩倉 澪 wrote:
> From what I've found, there was some work on this in the past (http://forum.dlang.org/thread/wokfqqbexazcguffwiif@forum.dlang.org?page=6#post-thclpgdlfxxhhfklwsoj:40forum.dlang.org), but a pull request was never made/I don't seem to find discussion about adding it as a feature anywhere.
>
> I think optional named parameters would be a nice addition, either to the core language, or something like the monadic solution from that old thread in phobos.
>
> Are there good reasons not to add something like this to the language, or is it simply a matter of doing the work? Has it been discussed much?

My limited Scala experience from several years ago suggests this is not something worth doing. The names of parameters are part of the API. Suppose you have a method like

def foo(x: int = 1000, y: double = 0.0): double {}

If you later change the names to something more informative

def foo(reps: int = 1000, variance: double = 0.0): double {}

you've potentially broken existing code. Maybe there are better approaches than that of Scala, but doing anything like that to D would be a huge mistake for little gain. (I write a lot of R code, for which named parameters are the norm, so I understand the convenience.)

bachmeier:

> def foo(x: int = 1000, y: double = 0.0): double {}
>
> If you later change the names to something more informative
>
> def foo(reps: int = 1000, variance: double = 0.0): double {}

You can use:

double foo(int deprecated(x) reps=100, deprecated(y) variance=0.0) {...}

Bye,
bearophile

On 10/13/2014 4:09 PM, bearophile wrote:
> bachmeier:
>
>> def foo(x: int = 1000, y: double = 0.0): double {}
>>
>> If you later change the names to something more informative
>>
>> def foo(reps: int = 1000, variance: double = 0.0): double {}
>
> You can use:
>
> double foo(int deprecated(x) reps=100, deprecated(y) variance=0.0) {...}

Please, no.

On Monday, 13 October 2014 at 10:53:50 UTC, ketmar via Digitalmars-d wrote:
> if we'll add proper AA literals, they can be used instead. methinks.

I think this would be a decent alternative.

On Monday, 13 October 2014 at 16:08:08 UTC, ponce wrote:
> Work-around I see a lot in C++:
>
> ---------------
>
> bool filled = true;
> drawCircle(filled);
>
> ---------------
>
> instead of:
>
> ---------------
>
> drawCircle(true);
>
> ---------------

This doesn't provide all the benefit of named parameters (in particular, their use in combination with default arguments

Other workarounds include associative arrays, and the so-called "Named Parameter Idiom" http://www.parashift.com/c++-faq-lite/named-parameter-idiom.html

On 10/13/14, 4:18 PM, Walter Bright wrote:
> On 10/13/2014 7:23 AM, Ary Borenszweig wrote:
>> On 10/13/14, 5:47 AM, Walter Bright wrote:
>>> On 10/13/2014 1:29 AM, "岩倉 澪" wrote:
>>>> Are there good reasons not to add something like this to the language,
>>>> or is it
>>>> simply a matter of doing the work? Has it been discussed much?
>>>
>>> Named parameters interact badly with overloading.
>>
>> Could you give an example?
>
> Nothing requires function overloads to use the same names in the same
> order for parameters. "color" can be the name for parameter 1 in one
> overload and for parameter 3 in another and not be there at all for a
> third.
>
> Parameters need not be named in D:
>
>     int foo(long);
>     int foo(ulong x);
>
> Named parameters are often desired so that default arguments need not be
> in order at the end:
>
>     int foo(int x = 5, int y);
>     int foo(int y, int z);
>
> To deal with all this, a number of arbitrary rules will have to be
> created. Overloading is already fairly complex, with the implemented
> notions of partial ordering. Even if this could all be settled, is it
> worth it? Can anyone write a document explaining this to people? Do
> people really want pages and pages of specification for this?

One simple thing we did in Crystal is to allow invoking a function with named arguments only for arguments that have a default value. For example:

void foo(int x, int y = 2, int z = 3) { ... }

foo(x, y: 10);
foo(x, y: 10, z: 20);
foo(x, z: 30)

But not this:

foo(x: 10)

The logic behind this is that named arguments are usually wanted when you want to replace one of the default values while keeping the others' defaults. You could specify names for arguments that don't have a default value, but that only gives a small readability aid. Changing a default value in the middle is a new feature.

This greatly simplifies the logic, since parameter reordering can only happen for names that have default values and you can always fill the gaps. Also, default values can also appear last in a function signature.