Will D ever get optional named parameters?

["岩倉 澪" via Digitalmars-d]

From what I've found, there was some work on this in the past
(http://forum.dlang.org/thread/wokfqqbexazcguffwiif at 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?

[Walter Bright via Digitalmars-d]

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.

[John Colvin via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by "岩倉 澪" via Digitalmars-d
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.

How so? Can't the overload just be calculated on the subset of
arguments that are given?

["岩倉 澪" via Digitalmars-d]

Post by Walter Bright via Digitalmars-d
Named parameters interact badly with overloading.

Good point, I hadn't thought of that!

[Paulo Pinto via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by "岩倉 澪" via Digitalmars-d
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.

Why? Both C# and Ada support overloading and named parameters.

--
Paulo

[Jacob Carlborg via Digitalmars-d]

Post by Walter Bright via Digitalmars-d
Named parameters interact badly with overloading.

Nothing says that named parameters means that you can pass the arguments
in any order. The linked forum post points to an implementation that
requires the arguments to be passed in the regular order.

[Ary Borenszweig via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

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?

[Walter Bright via Digitalmars-d]

Post by Ary Borenszweig via Digitalmars-d

Post by Walter Bright via Digitalmars-d

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?

[Meta via Digitalmars-d]

Post by Walter Bright via Digitalmars-d
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.
int foo(long);
int foo(ulong x);
Named parameters are often desired so that default arguments
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);

[Cliff via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by Ary Borenszweig via Digitalmars-d

Post by Walter Bright via Digitalmars-d

Post by "岩倉 澪" via Digitalmars-d
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.
int foo(long);
int foo(ulong x);
Named parameters are often desired so that default arguments
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.

[Shammah Chancellor via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by Ary Borenszweig via Digitalmars-d

Post by Walter Bright via Digitalmars-d

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.
int foo(long);
int foo(ulong x);
Named parameters are often desired so that default arguments need not
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.

[Ary Borenszweig via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by Ary Borenszweig via Digitalmars-d

Post by Walter Bright via Digitalmars-d

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.
int foo(long);
int foo(ulong x);
Named parameters are often desired so that default arguments need not be
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.

["岩倉 澪" via Digitalmars-d]

On Tuesday, 14 October 2014 at 03:34:06 UTC, Ary Borenszweig

Post by Ary Borenszweig via Digitalmars-d
One simple thing we did in Crystal is to allow invoking a
function with named arguments only for arguments that have a
void foo(int x, int y = 2, int z = 3) { ... }
foo(x, y: 10);
foo(x, y: 10, z: 20);
foo(x, z: 30)
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.

Another thought I had is that an alternative could be to have
some special syntax to say "use the default for this parameter."
I do not have experience implementing languages so perhaps I am
wrong, but it seems like it should be possible for the compiler
to get the default value and replace some placeholder with it.

Something like:
void foo(int a = 42, int b = 0){}
foo(@default, 7); //rewritten to foo(42, 7);

[via Digitalmars-d]

Post by "岩倉 澪" via Digitalmars-d
void foo(int a = 42, int b = 0){}

It is useful to have "_" mean "I don't care" when you have
tuples. So you would then write:

"foo( _ , 7 )" and " _,y = get_point()"

[ketmar via Digitalmars-d]

On Wed, 15 Oct 2014 11:21:43 +0000

Post by via Digitalmars-d

Post by "岩倉 澪" via Digitalmars-d
void foo(int a = 42, int b = 0){}

It is useful to have "_" mean "I don't care" when you have
"foo( _ , 7 )" and " _,y = get_point()"

it better be "__" (two underscores). the rationale is simple: "__" is
clearly reserved for internal use, so it can has any meaning we need
without breaking any code. 'cause single underscore now can be used as
placeholder in `foreach (_; 0..42)`, *AND* still can be accessed as
normal var. besides, nested foreach with '_' is not working. but "__"
can generate unique temporary variable each time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141015/855dafe0/attachment.sig>

[bearophile via Digitalmars-d]

Post by ketmar via Digitalmars-d
besides, nested foreach with '_' is not working. but "__"
can generate unique temporary variable each time.

The point is to introduce a little breaking change in D and use
"_" as "don't care", so you can reuse it for nested scoped and
for tuple unpacking, and for other similar future purposes.

Bye,
bearophile

[&quot;岩倉 澪&quot; via Digitalmars-d]

Post by bearophile via Digitalmars-d

Post by ketmar via Digitalmars-d
besides, nested foreach with '_' is not working. but "__"
can generate unique temporary variable each time.

The point is to introduce a little breaking change in D and use
"_" as "don't care", so you can reuse it for nested scoped and
for tuple unpacking, and for other similar future purposes.
Bye,
bearophile

I agree that _ would be the ideal syntax, but why make a breaking
change when it is unnecessary? __ would serve just as well and it
is only one extra character. It is already reserved so it would
be reasonable to put it to good use.

[Russel Winder via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by &quot;岩倉 澪&quot; via Digitalmars-d
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.

Groovy handles this OK.

(Python handles this fine by not having even a whiff of the
possibility of overloading ;-)

- --
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip:
sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[ketmar via Digitalmars-d]

On Mon, 13 Oct 2014 08:29:40 +0000

Post by &quot;岩倉 澪&quot; via Digitalmars-d
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.

if we'll add proper AA literals, they can be used instead. methinks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141013/e7951dd2/attachment.sig>

[ponce via Digitalmars-d]

Post by &quot;岩倉 澪&quot; via Digitalmars-d
From what I've found, there was some work on this in the past
(http://forum.dlang.org/thread/wokfqqbexazcguffwiif at 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?

Work-around I see a lot in C++:

---------------

bool filled = true;
drawCircle(filled);

---------------

instead of:

---------------

drawCircle(true);

---------------

[ketmar via Digitalmars-d]

On Mon, 13 Oct 2014 16:08:07 +0000

Post by ponce via Digitalmars-d
---------------
bool filled = true;
drawCircle(filled);
---------------
---------------
drawCircle(true);
---------------

it's not the same, i thing. for this we have Flag in std.typecons, for
example.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141013/e6b8552c/attachment.sig>

[bachmeier via Digitalmars-d]

Post by &quot;岩倉 澪&quot; via Digitalmars-d
From what I've found, there was some work on this in the past
(http://forum.dlang.org/thread/wokfqqbexazcguffwiif at 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.)

[bearophile via Digitalmars-d]

Post by bachmeier via Digitalmars-d
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

[Walter Bright via Digitalmars-d]

Post by bachmeier via Digitalmars-d
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 {}

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

Please, no.

[&quot;岩倉 澪&quot; via Digitalmars-d]

On Monday, 13 October 2014 at 10:53:50 UTC, ketmar via

Post by ketmar via Digitalmars-d
if we'll add proper AA literals, they can be used instead.
methinks.

I think this would be a decent alternative.

Post by ketmar via Digitalmars-d
---------------
bool filled = true;
drawCircle(filled);
---------------
---------------
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

[Rei Roldan via Digitalmars-d]

Post by &quot;岩倉 澪&quot; via Digitalmars-d
From what I've found, there was some work on this in the past
(http://forum.dlang.org/thread/wokfqqbexazcguffwiif at 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?

That's just taking laziness one step further :)