www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Named arguments via struct initialization in functions

reply Seb <seb wilzba.ch> writes:
Hey all,

I wanted to relive the discussion on named arguments and ping for 
its current status.

There is a bunch of examples to show how needed a unified 
solution for this problem is, let me give you one from phobos [2].

```
// I want to allow downsizing
iota(10).sliced!(Yes.replaceArrayWithPointer, 
Yes.allowDownsize)(4);
```

There is of course the alternative solution that an author 
overloads his function to the utmost, but this results in 
complexity and duplicated code (see e.g. redBlackTree in phobos 
[3]).

Currently the best solution AFAICT is to use a struct to pass 
such flags, like

```
struct Options{int x; int y=1; int z=2;}
auto fun(Options options)
{
     return options.x + options.y + options.z;
}

Options options = {x: 4, z: 3};
auto a=fun(options);
```

There are also other workarounds as discussed in [1] (e.g. with 
CTFE string analysis [4]).

I general there two solutions to this problem
1) get true named parameters support in D (probably complicated)
2) allow struct inits in functions - e.g. fun({x: 4})

For 2) Jacob Carlborg has proposed something similar three years 
ago. In his case he proposed anonymous structs which might be 
more generally applicable, however just created the struct seems 
easier and allows more
It doesn't seem that complicated to me as the compiler already 
knows the type of the argument.

Using structs is not ideal, because one can't require parameters, 
but this can be solved by having those parameters as normal ones 
like `sliced(4, {allowDownsize: true})` and it creates some maybe 
unnecessary overhead.
However it is probably the easiest solution right now.

What are your thoughts on this issue?

On a side note: many templated functions are also complicated and 
experiencing this issue, so it also might be worth to think about 
this issue too ;-)

Cheers,

Seb

[1] 
http://forum.dlang.org/post/pxndhoskpjxvnoacajaz forum.dlang.org
[2] https://github.com/DlangScience/mir/issues/18
[3] 
https://github.com/D-Programming-Language/phobos/pull/4041/files
[4] 
https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d
Mar 06 2016
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Sun, 06 Mar 2016 17:35:38 +0000, Seb wrote:


 Hey all,
 
 I wanted to relive the discussion on named arguments and ping for its
 current status.


We want something to let people provide arguments sparsely and 
unambiguously, and if possible in arbitrary order. The existing DIP just 
lets you provide compiler-checked annotations to verify the parameter 
names match your expectations, assuming the writer of the function chose 
to allow it.

Nobody much liked it. I've got a draft DIP on my hard drive to provide 
actual named arguments but haven't gotten around to proposing it.

There was considerable disagreement on whether the function parameters 
should be explicitly marked in order to use them as named or not. Scala, 

Ruby and Dart require you to mark them.

There are a couple other interesting decisions regarding named 
parameters, but nobody much considered them during the discussion. 
Ceylon's the most permissive example.


 2) allow struct inits in functions - e.g. fun({x: 4})


I looked into this a bit. I've got another draft DIP for it on my hard 
drive. There are two obvious ambiguities:

  struct A { int x; long y; }
  struct B { int x; string y; }
  void foo(A a) {}
  void foo(B b) {}
  foo({x: 1});

There's no way to tell which overload to invoke.

Then let's say I added:
  void foo(void delegate() dg) {}
  foo({});

That could be a default-initialized struct of type A or B, or it could be 
a no-op delegate.

You can resolve that with a slightly different syntax:

  foo(A{x: 1});

I think I noticed an ambiguity with that, too, but I can't recall now. I 
failed to write it down in any case.

Anyway, if it works, it's an improvement. And you only need explicit type 
marking at the top level; it's unambiguous after that.
Mar 06 2016
parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Sunday, 6 March 2016 at 19:10:50 UTC, Chris Wright wrote:

 On Sun, 06 Mar 2016 17:35:38 +0000, Seb wrote:


 [...]


 We want something to let people provide arguments sparsely and 
 unambiguously, and if possible in arbitrary order. The existing 
 DIP just lets you provide compiler-checked annotations to 
 verify the parameter names match your expectations, assuming 
 the writer of the function chose to allow it.

 Nobody much liked it. I've got a draft DIP on my hard drive to 
 provide actual named arguments but haven't gotten around to 
 proposing it.

 There was considerable disagreement on whether the function 
 parameters should be explicitly marked in order to use them as 

 don't require you to mark them. Ruby and Dart require you to 
 mark them.

 There are a couple other interesting decisions regarding named 
 parameters, but nobody much considered them during the 
 discussion. Ceylon's the most permissive example.


 [...]


 I looked into this a bit. I've got another draft DIP for it on 
 my hard drive. There are two obvious ambiguities:

   struct A { int x; long y; }
   struct B { int x; string y; }
   void foo(A a) {}
   void foo(B b) {}
   foo({x: 1});

 There's no way to tell which overload to invoke.

 Then let's say I added:
   void foo(void delegate() dg) {}
   foo({});

 That could be a default-initialized struct of type A or B, or 
 it could be a no-op delegate.

 You can resolve that with a slightly different syntax:

   foo(A{x: 1});

 I think I noticed an ambiguity with that, too, but I can't 
 recall now. I failed to write it down in any case.


The compiler should detect that this call is ambiguous and would 
not allow it.

To resolve the ambiguity, the user can write:
foo(A{ x: 1 });
foo(B{ x: 1 });
foo(() { });
foo(delegate void() { });

Which I think is a very reasonably requirement.

Do you have any other examples of ambiguity that can't be easily 
resolved?


 Anyway, if it works, it's an improvement.


Yep.


 And you only need explicit type marking at the top level;
 it's unambiguous after that.


I'm not sure what you mean by "explicit type marking at the top 
level".
Mar 07 2016
parent reply Chris Wright <dhasenan gmail.com> writes:
On Mon, 07 Mar 2016 11:06:13 +0000, ZombineDev wrote:

 The compiler should detect that this call is ambiguous and would not
 allow it.


It's a potentially significant amount of work to determine that the 
expression is ambiguous, or to disambiguate.


 To resolve the ambiguity, the user can write:
 foo(A{ x: 1 });


That's why I suggested it.


 And you only need explicit type marking at the top level;
 it's unambiguous after that.


 
 I'm not sure what you mean by "explicit type marking at the top level".


It always is unambiguous to write things like:
  auto a = A{x: {y: 1}};
Mar 07 2016
parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Monday, 7 March 2016 at 19:06:54 UTC, Chris Wright wrote:

 On Mon, 07 Mar 2016 11:06:13 +0000, ZombineDev wrote:

 The compiler should detect that this call is ambiguous and 
 would not allow it.


 It's a potentially significant amount of work to determine that 
 the expression is ambiguous, or to disambiguate.


I don't think so. At least not much more than what currently the 
compiler does for overload resolution (comparing the void(A) 
overloard to the void(B)). Tuples literals / struct initializer 
literals / delegates should be classified before the end of the 
parsing phase (which is actually at least an order of magnitude 
faster than the semantic phase).


 To resolve the ambiguity, the user can write:
 foo(A{ x: 1 });


 That's why I suggested it.


 And you only need explicit type marking at the top level; 
 it's unambiguous after that.


 
 I'm not sure what you mean by "explicit type marking at the 
 top level".


 It always is unambiguous to write things like:
   auto a = A{x: {y: 1}};


Ah ok, agreed.
Mar 10 2016
parent reply Chris Wright <dhasenan gmail.com> writes:
On Thu, 10 Mar 2016 19:01:53 +0000, ZombineDev wrote:


 On Monday, 7 March 2016 at 19:06:54 UTC, Chris Wright wrote:

 On Mon, 07 Mar 2016 11:06:13 +0000, ZombineDev wrote:

 The compiler should detect that this call is ambiguous and would not
 allow it.


 It's a potentially significant amount of work to determine that the
 expression is ambiguous, or to disambiguate.


 
 I don't think so. At least not much more than what currently the
 compiler does for overload resolution (comparing the void(A) overloard
 to the void(B)).


Currently, overload resolution deals with a similar problem with numeric 
literals. But there's a big difference between supporting it for one 
class of related types that's all known at compile time, and supporting 
it for an open-ended set of types that are entirely unrelated.

If I were implement this, the first pass would require struct literal 
expressions to include the struct type. I might later consider whether to 
change that.


 Tuples literals / struct initializer literals /
 delegates should be classified before the end of the parsing phase


That is, you can determine whether something is a delegate literal or a 
struct literal (even without marking struct literals with their type) 
during parsing. For a moment, I misunderstood and thought you were 
talking about assigning types to them.


 (which is actually at least an order of magnitude faster than the
 semantic phase).


It wouldn't be parseable with an LL(k) parser, which is a minor thing. 
More to the point, depending on how DMD's parser is designed, it might be 
pretty awkward to parse something that might be a labeled statement or a 
struct variable initializer.

If we can get something that's approximately as good (arguably better 
because it's less ambiguous, arguably worse because it's more to type) 
with far less work, then, given the small number of people who contribute 
to DMD, it would behoove us to choose the easier option.
Mar 10 2016
parent ZombineDev <petar.p.kirov gmail.com> writes:
On Friday, 11 March 2016 at 05:09:44 UTC, Chris Wright wrote:

 On Thu, 10 Mar 2016 19:01:53 +0000, ZombineDev wrote:


 On Monday, 7 March 2016 at 19:06:54 UTC, Chris Wright wrote:

 On Mon, 07 Mar 2016 11:06:13 +0000, ZombineDev wrote:

 The compiler should detect that this call is ambiguous and 
 would not allow it.


 It's a potentially significant amount of work to determine 
 that the expression is ambiguous, or to disambiguate.


 
 I don't think so. At least not much more than what currently 
 the
 compiler does for overload resolution (comparing the void(A) 
 overloard
 to the void(B)).


 Currently, overload resolution deals with a similar problem 
 with numeric literals. But there's a big difference between 
 supporting it for one class of related types that's all known 
 at compile time, and supporting it for an open-ended set of 
 types that are entirely unrelated.


It's not open-ended - size of the set is equal to the number of 
overloads taking structs, which in practice should be less than 
20.


 If I were implement this, the first pass would require struct 
 literal expressions to include the struct type. I might later 
 consider whether to change that.


I'm OK with this. Even in the future we'll still need this, 
because with templates, type inference would not be possible.


 Tuples literals / struct initializer literals /
 delegates should be classified before the end of the parsing 
 phase


 That is, you can determine whether something is a delegate 
 literal or a struct literal (even without marking struct 
 literals with their type) during parsing. For a moment, I 
 misunderstood and thought you were talking about assigning 
 types to them.


Yes, I meant just coarse-grained AST categorization, not type 
inference. We need this to be a simple process both ease the 
implementation, as well as the human reader. Ideally, the user 
should be able to tell the difference at a glance.


 (which is actually at least an order of magnitude faster than 
 the
 semantic phase).


 It wouldn't be parseable with an LL(k) parser, which is a minor 
 thing. More to the point, depending on how DMD's parser is 
 designed, it might be pretty awkward to parse something that 
 might be a labeled statement or a struct variable initializer.


Since DMD's parser is hand-written (and not generated from a 
grammer), I don't think it's design would be a problem. AFAIR, it 
uses arbitrary lookahead for a couple of things, because it is 
easier or faster.



 If we can get something that's approximately as good (arguably 
 better because it's less ambiguous, arguably worse because it's 
 more to type) with far less work, then, given the small number 
 of people who contribute to DMD, it would behoove us to choose 
 the easier option.


I don't think that the implementation would be a problem if we 
can convince Walter and Andrei. From what I've read in old 
bugzilla issues, they're both supportive of the idea of dedicated 
tuple syntax, however they wanted to hold from individual 
enhancements, in favour of a holistic design.
Mar 11 2016
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-03-06 18:35, Seb wrote:

 Hey all,

 I wanted to relive the discussion on named arguments and ping for its
 current status.

 There is a bunch of examples to show how needed a unified solution for
 this problem is, let me give you one from phobos [2].

 ```
 // I want to allow downsizing
 iota(10).sliced!(Yes.replaceArrayWithPointer, Yes.allowDownsize)(4);
 ```

 There is of course the alternative solution that an author overloads his
 function to the utmost, but this results in complexity and duplicated
 code (see e.g. redBlackTree in phobos [3]).

 Currently the best solution AFAICT is to use a struct to pass such
 flags, like

 ```
 struct Options{int x; int y=1; int z=2;}
 auto fun(Options options)
 {
      return options.x + options.y + options.z;
 }

 Options options = {x: 4, z: 3};
 auto a=fun(options);
 ```

 There are also other workarounds as discussed in [1] (e.g. with CTFE
 string analysis [4]).

 I general there two solutions to this problem
 1) get true named parameters support in D (probably complicated)
 2) allow struct inits in functions - e.g. fun({x: 4})

 For 2) Jacob Carlborg has proposed something similar three years ago. In
 his case he proposed anonymous structs which might be more generally
 applicable, however just created the struct seems easier and allows more
 It doesn't seem that complicated to me as the compiler already knows the
 type of the argument.

 Using structs is not ideal, because one can't require parameters, but
 this can be solved by having those parameters as normal ones like
 `sliced(4, {allowDownsize: true})` and it creates some maybe unnecessary
 overhead.
 However it is probably the easiest solution right now.

 What are your thoughts on this issue?


I think the simplest solution is to allow struct member initializer in 
all places a struct literal is accepted [1].

[1] https://issues.dlang.org/show_bug.cgi?id=15692

-- 
/Jacob Carlborg
Mar 06 2016
parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Sunday, 6 March 2016 at 20:35:49 UTC, Jacob Carlborg wrote:

 On 2016-03-06 18:35, Seb wrote:

 Hey all,

 I wanted to relive the discussion on named arguments and ping 
 for its
 current status.

 There is a bunch of examples to show how needed a unified 
 solution for
 this problem is, let me give you one from phobos [2].

 ```
 // I want to allow downsizing
 iota(10).sliced!(Yes.replaceArrayWithPointer, 
 Yes.allowDownsize)(4);
 ```

 There is of course the alternative solution that an author 
 overloads his
 function to the utmost, but this results in complexity and 
 duplicated
 code (see e.g. redBlackTree in phobos [3]).

 Currently the best solution AFAICT is to use a struct to pass 
 such
 flags, like

 ```
 struct Options{int x; int y=1; int z=2;}
 auto fun(Options options)
 {
      return options.x + options.y + options.z;
 }

 Options options = {x: 4, z: 3};
 auto a=fun(options);
 ```

 There are also other workarounds as discussed in [1] (e.g. 
 with CTFE
 string analysis [4]).

 I general there two solutions to this problem
 1) get true named parameters support in D (probably 
 complicated)
 2) allow struct inits in functions - e.g. fun({x: 4})

 For 2) Jacob Carlborg has proposed something similar three 
 years ago. In
 his case he proposed anonymous structs which might be more 
 generally
 applicable, however just created the struct seems easier and 
 allows more
 It doesn't seem that complicated to me as the compiler already 
 knows the
 type of the argument.

 Using structs is not ideal, because one can't require 
 parameters, but
 this can be solved by having those parameters as normal ones 
 like
 `sliced(4, {allowDownsize: true})` and it creates some maybe 
 unnecessary
 overhead.
 However it is probably the easiest solution right now.

 What are your thoughts on this issue?


 I think the simplest solution is to allow struct member 
 initializer in all places a struct literal is accepted [1].

 [1] https://issues.dlang.org/show_bug.cgi?id=15692


+100

This can also pave the way for tuple literals, e.g.:
// nothing new, ordinary struct member init
Point2 point = { x: 3, y: 4 };

// auto variables are deduced to be tuples

auto plainTuple = { 10, "hi", 3.14 }; // See also DIP32

Which I don't think will cause ambiguity with delegates:
auto tuple3 = { getInt() }; tuple
auto tuple3 = { getInt(); }; lambda

// unambiguous (disallow delegates that contain only CommaExpr):
auto tuple4 = { getInt(), getString(), getDouble() };
Mar 07 2016
parent reply Meta <jared771 gmail.com> writes:
On Monday, 7 March 2016 at 10:40:15 UTC, ZombineDev wrote:

 Which I don't think will cause ambiguity with delegates:
 auto tuple3 = { getInt() }; tuple
 auto tuple3 = { getInt(); }; lambda


Unfortunately this will not work. There was a tuple proposal 
sometime back in 2012 or 2013. I can't remember the exact reason, 
but somebody came up with a case where it can be ambiguous as to 
whether it's a tuple or a delegate.
Mar 07 2016
next sibling parent Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:

 On Monday, 7 March 2016 at 10:40:15 UTC, ZombineDev wrote:

 Which I don't think will cause ambiguity with delegates:
 auto tuple3 = { getInt() }; tuple
 auto tuple3 = { getInt(); }; lambda


 Unfortunately this will not work. There was a tuple proposal 
 sometime back in 2012 or 2013. I can't remember the exact 
 reason, but somebody came up with a case where it can be 
 ambiguous as to whether it's a tuple or a delegate.


I believe it was the empty tuple, which is indistinguishable from 
a do-nothing lambda.

     pragma(msg, typeof({}));
     // prints:
     // void function() pure nothrow  nogc  safe

Nothing that can't be solved, I'd say. Just define `{}` to mean 
one of them and provide a workaround for the other one.

OTOH, distinguishing between tuples and lambdas requires 
unlimited lookahead and backtracking, which can become expensive 
for pathological cases.
Mar 08 2016
prev sibling parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:

 On Monday, 7 March 2016 at 10:40:15 UTC, ZombineDev wrote:

 Which I don't think will cause ambiguity with delegates:
 auto tuple3 = { getInt() }; tuple
 auto tuple3 = { getInt(); }; lambda


 Unfortunately this will not work. There was a tuple proposal 
 sometime back in 2012 or 2013. I can't remember the exact 
 reason, but somebody came up with a case where it can be 
 ambiguous as to whether it's a tuple or a delegate.


Can you find the exact case? I'm really interested in getting 
proper tuple syntax support and I think that's important to cover 
all the possible cases before can agree on something and move 
towards implementing it.
Mar 10 2016
parent reply Meta <jared771 gmail.com> writes:
On Thursday, 10 March 2016 at 19:36:05 UTC, ZombineDev wrote:

 On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:

 On Monday, 7 March 2016 at 10:40:15 UTC, ZombineDev wrote:

 Which I don't think will cause ambiguity with delegates:
 auto tuple3 = { getInt() }; tuple
 auto tuple3 = { getInt(); }; lambda


 Unfortunately this will not work. There was a tuple proposal 
 sometime back in 2012 or 2013. I can't remember the exact 
 reason, but somebody came up with a case where it can be 
 ambiguous as to whether it's a tuple or a delegate.


 Can you find the exact case? I'm really interested in getting 
 proper tuple syntax support and I think that's important to 
 cover all the possible cases before can agree on something and 
 move towards implementing it.


Here's the thread where it's pointed out: 
http://forum.dlang.org/post/mailman.372.1364547485.4724.digitalmars-d puremagic.com

And here's Kenji's DIP:
http://wiki.dlang.org/DIP32
Mar 11 2016
next sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Friday, 11 March 2016 at 13:26:49 UTC, Meta wrote:

 On Thursday, 10 March 2016 at 19:36:05 UTC, ZombineDev wrote:

 On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:

 Unfortunately this will not work. There was a tuple proposal 
 sometime back in 2012 or 2013. I can't remember the exact 
 reason, but somebody came up with a case where it can be 
 ambiguous as to whether it's a tuple or a delegate.


 Can you find the exact case? I'm really interested in getting 
 proper tuple syntax support and I think that's important to 
 cover all the possible cases before can agree on something and 
 move towards implementing it.


 Here's the thread where it's pointed out: 
 http://forum.dlang.org/post/mailman.372.1364547485.4724.digitalmars-d puremagic.com


Aside from the empty tuple, I can only find Timon's comment:
http://forum.dlang.org/post/kj44fs$2iil$1 digitalmars.com


 0 "Inside tuple literal, ; never appears."
   {{;}}           // a tuple not matching your specification
   {{if(foo()){}}} // a non-tuple matching your specification


This is not a serious problem, because it just means that the DIP 
needs to be rephrased. There is no actual ambiguity.


 And here's Kenji's DIP:
 http://wiki.dlang.org/DIP32
Mar 11 2016
parent Chris Wright <dhasenan gmail.com> writes:
On Fri, 11 Mar 2016 14:29:39 +0000, Marc Schütz wrote:

 0 "Inside tuple literal, ; never appears."
   {{;}}           // a tuple not matching your specification
   {{if(foo()){}}} // a non-tuple matching your specification


 
 This is not a serious problem, because it just means that the DIP needs
 to be rephrased. There is no actual ambiguity.


{{if(foo()){}}} looks like a tuple containing a delegate or a delegate 
containing a BlockStatement.

{} looks like an empty tuple and an empty void delegate().

The proposal resolves the ambiguity by fiat: ambiguous things are 
classified as tuples. This is a breaking change and should have been 
called out in the proposal.
Mar 11 2016
prev sibling parent ZombineDev <petar.p.kirov gmail.com> writes:
On Friday, 11 March 2016 at 13:26:49 UTC, Meta wrote:

 On Thursday, 10 March 2016 at 19:36:05 UTC, ZombineDev wrote:

 On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:

 [...]


 Can you find the exact case? I'm really interested in getting 
 proper tuple syntax support and I think that's important to 
 cover all the possible cases before can agree on something and 
 move towards implementing it.


 Here's the thread where it's pointed out: 
 http://forum.dlang.org/post/mailman.372.1364547485.4724.digitalmars-d puremagic.com

 And here's Kenji's DIP:
 http://wiki.dlang.org/DIP32


Thanks, I had read the DIP, but couldn't find the forum 
discussion. I added the link to the wiki page.
Mar 11 2016
prev sibling next sibling parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Sunday, 6 March 2016 at 17:35:38 UTC, Seb wrote:

 Hey all,

 I wanted to relive the discussion on named arguments and ping 
 for its current status.

 There is a bunch of examples to show how needed a unified 
 solution for this problem is, let me give you one from phobos 
 [2].

 ```
 // I want to allow downsizing
 iota(10).sliced!(Yes.replaceArrayWithPointer, 
 Yes.allowDownsize)(4);
 ```

 There is of course the alternative solution that an author 
 overloads his function to the utmost, but this results in 
 complexity and duplicated code (see e.g. redBlackTree in phobos 
 [3]).

 Currently the best solution AFAICT is to use a struct to pass 
 such flags, like

 ```
 struct Options{int x; int y=1; int z=2;}
 auto fun(Options options)
 {
     return options.x + options.y + options.z;
 }

 Options options = {x: 4, z: 3};
 auto a=fun(options);
 ```

 There are also other workarounds as discussed in [1] (e.g. with 
 CTFE string analysis [4]).

 I general there two solutions to this problem
 1) get true named parameters support in D (probably complicated)
 2) allow struct inits in functions - e.g. fun({x: 4})

 For 2) Jacob Carlborg has proposed something similar three 
 years ago. In his case he proposed anonymous structs which 
 might be more generally applicable, however just created the 
 struct seems easier and allows more
 It doesn't seem that complicated to me as the compiler already 
 knows the type of the argument.

 Using structs is not ideal, because one can't require 
 parameters, but this can be solved by having those parameters 
 as normal ones like `sliced(4, {allowDownsize: true})` and it 
 creates some maybe unnecessary overhead.
 However it is probably the easiest solution right now.

 What are your thoughts on this issue?

 On a side note: many templated functions are also complicated 
 and experiencing this issue, so it also might be worth to think 
 about this issue too ;-)

 Cheers,


What about this idea? A new word "as" or something similar.

You have defined:

int fun(int x=100, int y=100, int r=100){...}


int xpos=100;
int ypos=100;
int radius=50;


Now you are allowed to call:
fun(xpos,ypos,radius);  // normal nothing has changed!

Call with "as":

fun(ypos as y, xpos as x, radius as r); // different order!

or

fun(radius as r);  // defaults values are used.
<=>
fun(,,radius);

The compiler is looking for the right mapping?
Mar 08 2016
parent reply Chris Wright <dhasenan gmail.com> writes:
On Tue, 08 Mar 2016 13:52:09 +0000, Martin Tschierschke wrote:

 What about this idea? A new word "as" or something similar.
 fun(ypos as y, xpos as x, radius as r); // different order!


The syntax isn't an issue.

There was one DIP about named parameters, but it was unpopular. It didn't 
change *anything* about overload resolution; it only had the compiler 
check that you provided arguments in the correct order, even if they were 
all of the same type.

Even if there were a DIP everyone liked, nobody is signing up to 
implement it. DDMD is a little scary and not reflective of good design in 
D (having been translated by machine from C++).

I might take a look, but I probably won't have the time to produce 
anything useful.
Mar 08 2016
parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Tuesday, 8 March 2016 at 18:46:02 UTC, Chris Wright wrote:

 On Tue, 08 Mar 2016 13:52:09 +0000, Martin Tschierschke wrote:

 What about this idea? A new word "as" or something similar. 
 fun(ypos as y, xpos as x, radius as r); // different order!


 The syntax isn't an issue.

 There was one DIP about named parameters, but it was unpopular. 
 It didn't change *anything* about overload resolution; it only 
 had the compiler check that you provided arguments in the 
 correct order, even if they were all of the same type.

 Even if there were a DIP everyone liked, nobody is signing up 
 to implement it. DDMD is a little scary and not reflective of 
 good design in D (having been translated by machine from C++).

 I might take a look, but I probably won't have the time to 
 produce anything useful.


I have seen the "DIP about named parameters", and i liked the idea
of getting a easier to read code, because it gets more verbose.

My idea with the  "val as x" was to avoid the need to define the 
functions in a
different way. But as Idan Arye pointed out, it seems to be more 
difficult:

"As far as I understand, the main two problems with named 
arguments are overloading ambiguity and the fact that argument 
names are not part of the signature."

An other point on my wish list would be to allow string symbol 
notation
like in ruby. Than using hashes (AA) for parameters gets more 
convenient:

:symbol <= just short for => "symbol"

h[:y]= 50; h[:x] = 100; // <=> h["y"] = 50; h["x"] = 100

For calling a function:
auto params = [:y : 50, :x : 100] <=> auto params = ["y" : 50 , 
"x" : 100]

Especially when the code is nested in a string for mixin purpose. 
(vibe.d templates).

But maybe this crashes, because of
the ambiguity if no space after a ":" is used in this place:
auto hash = [ 1 :variable] meaning: auto hash = [ 1 : variable ]
not auto hash = [1 "variable" ] which would make no sense either.
Mar 09 2016
parent reply Idan Arye <GenericNPC gmail.com> writes:
On Wednesday, 9 March 2016 at 10:06:25 UTC, Martin Tschierschke 
wrote:

 On Tuesday, 8 March 2016 at 18:46:02 UTC, Chris Wright wrote:

 On Tue, 08 Mar 2016 13:52:09 +0000, Martin Tschierschke wrote:

 What about this idea? A new word "as" or something similar. 
 fun(ypos as y, xpos as x, radius as r); // different order!


 The syntax isn't an issue.

 There was one DIP about named parameters, but it was 
 unpopular. It didn't change *anything* about overload 
 resolution; it only had the compiler check that you provided 
 arguments in the correct order, even if they were all of the 
 same type.

 Even if there were a DIP everyone liked, nobody is signing up 
 to implement it. DDMD is a little scary and not reflective of 
 good design in D (having been translated by machine from C++).

 I might take a look, but I probably won't have the time to 
 produce anything useful.


 I have seen the "DIP about named parameters", and i liked the 
 idea
 of getting a easier to read code, because it gets more verbose.

 My idea with the  "val as x" was to avoid the need to define 
 the functions in a
 different way. But as Idan Arye pointed out, it seems to be 
 more difficult:

 "As far as I understand, the main two problems with named 
 arguments are overloading ambiguity and the fact that argument 
 names are not part of the signature."

 An other point on my wish list would be to allow string symbol 
 notation
 like in ruby. Than using hashes (AA) for parameters gets more 
 convenient:

 :symbol <= just short for => "symbol"

 h[:y]= 50; h[:x] = 100; // <=> h["y"] = 50; h["x"] = 100

 For calling a function:
 auto params = [:y : 50, :x : 100] <=> auto params = ["y" : 50 , 
 "x" : 100]

 Especially when the code is nested in a string for mixin 
 purpose. (vibe.d templates).

 But maybe this crashes, because of
 the ambiguity if no space after a ":" is used in this place:
 auto hash = [ 1 :variable] meaning: auto hash = [ 1 : variable ]
 not auto hash = [1 "variable" ] which would make no sense 
 either.


String symbols are Ruby's(and many Lisps', and maybe some other, 
less popular languages) way to do untyped enums and untyped 
structs. It's a dynamically typed languages thing and has no room 
in statically typed languages like D. D mimics dynamic typing to 
some extent by creating types on the fly with it's powerful 
templates mechanism - but a new type still needs to be created. D 
is geared toward reflection on types at compile time, not towards 
type detection at run-time...

Allowing something like `auto params = [:y : 50, :x : 100]` won't 
really solve anything. It works nicely in Ruby, because Ruby has 
dynamic typing and with some syntactic sugar you get elegant 
syntax for dynamic structs. But in a structured language like D, 
you run into the problem that `[:y : 50, :x : 100] is an 
associative array with a determined type for it's values, so you 
can't do things like `[:y : 50, :x : "hello"]` - which greatly 
limits the usability of this syntax.
Mar 09 2016
next sibling parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Wednesday, 9 March 2016 at 12:55:16 UTC, Idan Arye wrote:
[...]

 An other point on my wish list would be to allow string symbol 
 notation
 like in ruby. Than using hashes (AA) for parameters gets more 
 convenient:

 :symbol <= just short for => "symbol"

 h[:y]= 50; h[:x] = 100; // <=> h["y"] = 50; h["x"] = 100






 String symbols are Ruby's(and many Lisps', and maybe some 
 other, less popular languages) way to do untyped enums and 
 untyped structs. It's a dynamically typed languages thing and 
 has no room in statically typed languages like D. D mimics 
 dynamic typing to some extent by creating types on the fly with 
 it's powerful templates mechanism - but a new type still needs 
 to be created. D is geared toward reflection on types at 
 compile time, not towards type detection at run-time...


Thats true.

 Allowing something like `auto params = [:y : 50, :x : 100]` 
 won't really solve anything. It works nicely in Ruby, because 
 Ruby has dynamic typing and with some syntactic sugar you get 
 elegant syntax for dynamic structs. But in a structured 
 language like D, you run into the problem that `[:y : 50, :x : 
 100] is an associative array with a determined type for it's 
 values, so you can't do things like `[:y : 50, :x : "hello"]` - 
 which greatly limits the usability of this syntax.


Yes.Ok.
What I like about the :symbol notation is, that a string witch is 
used
only to distinguish between different objects in an Hash / AA has 
a complete different
purpose than a string used to be displayed for the user.

I think that
           writeln("Name", a[:name]); is easier to read, than
           writeln("Name", a["name"]);

especially if the structures are getting bigger, or you are in a 
vibe.d jade template string where you would have to use 
additional quoting to write:

           a(href="a[\"url\"]") a["link_text"]

           a(href="a[:url]") a[:link_text]

May be I should get rid of this by using a struct for my mysql 
results to display?
(=> a.url and a.link_text )

Just my 2 Cents :-)
Mar 09 2016
parent Idan Arye <GenericNPC gmail.com> writes:
On Wednesday, 9 March 2016 at 13:39:57 UTC, Martin Tschierschke 
wrote:

 On Wednesday, 9 March 2016 at 12:55:16 UTC, Idan Arye wrote:
 [...]

 [...]






 [...]


 Thats true.

 [...]


 Yes.Ok.
 What I like about the :symbol notation is, that a string witch 
 is used
 only to distinguish between different objects in an Hash / AA 
 has a complete different
 purpose than a string used to be displayed for the user.

 I think that
           writeln("Name", a[:name]); is easier to read, than
           writeln("Name", a["name"]);

 especially if the structures are getting bigger, or you are in 
 a vibe.d jade template string where you would have to use 
 additional quoting to write:

           a(href="a[\"url\"]") a["link_text"]

           a(href="a[:url]") a[:link_text]

 May be I should get rid of this by using a struct for my mysql 
 results to display?
 (=> a.url and a.link_text )

 Just my 2 Cents :-)


If nested strings is what's bothering you, you can always use 
backticks. Or opDispatch(though I don't recommend it, as it tends 
to screw up compilation errors). But these won't let you have 
fields with different types, and since Voldemort types are so 
easy in D you are probably better off with structs.
Mar 09 2016
prev sibling parent reply Michael Coulombe <kirsybuu gmail.com> writes:
On Wednesday, 9 March 2016 at 12:55:16 UTC, Idan Arye wrote:

 Allowing something like `auto params = [:y : 50, :x : 100]` 
 won't really solve anything. It works nicely in Ruby, because 
 Ruby has dynamic typing and with some syntactic sugar you get 
 elegant syntax for dynamic structs. But in a structured 
 language like D, you run into the problem that `[:y : 50, :x : 
 100] is an associative array with a determined type for it's 
 values, so you can't do things like `[:y : 50, :x : "hello"]` - 
 which greatly limits the usability of this syntax.


I posted (in a previous thread about this issue) a library 
solution to this:

import std.typecons, std.meta;
private struct Named(string n, T) {
     enum name = n;
     T value;
}
template NamedToAS(N...) {
     static if (N.length == 0) {
         alias NamedToAS = AliasSeq!();
     }
     else {
         alias NamedToAS = AliasSeq!(typeof(N[0].init.value), 
N[0].name, NamedToAS!(N[1 .. $]));
     }
}
struct Tup {
     static auto opDollar(size_t i)() {
         return immutable KeyWordDollar();
     }
     static auto opIndex(NamedArgs...)(NamedArgs nas) {
         Tuple!(NamedToAS!NamedArgs) tup;
         foreach(i, ref na ; tup) {
             na = nas[i].value;
         }
         return tup;
     }
}
void overrideFrom(TupDef, TupOver)(ref TupDef defaultMap, ref 
TupOver overrideMap) {
     foreach(i, ref field ; overrideMap) {
         __traits(getMember, defaultMap, TupOver.fieldNames[i]) = 
field;
     }
}
auto println(KWA)(KWA kwa) {
     auto args = Tup[$.str = "abc", $.repeat = 2, $.sep = " "];
     args.overrideFrom(kwa);
     import std.stdio;
     bool first = true;
     foreach(i ; 0 .. args.repeat) {
         if (first) first = false; else write(args.sep);
         write(args.str);
     }
     writeln();
}
unittest {
     println(Tup[$.str = "xyz", $.repeat = 8]);
}
Mar 09 2016
parent Michael Coulombe <kirsybuu gmail.com> writes:
On Thursday, 10 March 2016 at 05:17:03 UTC, Michael Coulombe 
wrote:

 [...]


Whoops, forgot this:

private immutable struct KeyWordDollar {
      property
     auto opDispatch(string param, T)(T t) {
         return Named!(param,T)(t);
     }
}
Mar 09 2016
prev sibling next sibling parent arturg <var.spool.mail700 gmail.com> writes:
hi, has the UDA syntax been proposed already?

void fun(int foo, int bar, int bazDaz = 0){}

fun(10, 30, 50); // normal
fun(10, 30); normal with default

fun(10, 30,  bazDaz 50); // mixed
fun( bazDaz 50, 10, 30) // mixed and reordered
fun( bar 30, 10); // mixed, reordered and default

fun( foo 10,  bar 30,  bazDaz 50); // named
fun( bar 30,  bazDaz 50,  foo 10); // named and reordered

 foo int a = 10;
 bar int b = 30;
 bazDaz int c = 50;

fun(c, a, b); // hm allowed or not?

but if built in tuples could be used to do named args then it 
might be better to have those.
Mar 08 2016
prev sibling next sibling parent reply Idan Arye <GenericNPC gmail.com> writes:
On Sunday, 6 March 2016 at 17:35:38 UTC, Seb wrote:

 Hey all,

 I wanted to relive the discussion on named arguments and ping 
 for its current status.

 There is a bunch of examples to show how needed a unified 
 solution for this problem is, let me give you one from phobos 
 [2].

 ```
 // I want to allow downsizing
 iota(10).sliced!(Yes.replaceArrayWithPointer, 
 Yes.allowDownsize)(4);
 ```

 There is of course the alternative solution that an author 
 overloads his function to the utmost, but this results in 
 complexity and duplicated code (see e.g. redBlackTree in phobos 
 [3]).

 Currently the best solution AFAICT is to use a struct to pass 
 such flags, like

 ```
 struct Options{int x; int y=1; int z=2;}
 auto fun(Options options)
 {
     return options.x + options.y + options.z;
 }

 Options options = {x: 4, z: 3};
 auto a=fun(options);
 ```

 There are also other workarounds as discussed in [1] (e.g. with 
 CTFE string analysis [4]).

 I general there two solutions to this problem
 1) get true named parameters support in D (probably complicated)
 2) allow struct inits in functions - e.g. fun({x: 4})

 For 2) Jacob Carlborg has proposed something similar three 
 years ago. In his case he proposed anonymous structs which 
 might be more generally applicable, however just created the 
 struct seems easier and allows more
 It doesn't seem that complicated to me as the compiler already 
 knows the type of the argument.

 Using structs is not ideal, because one can't require 
 parameters, but this can be solved by having those parameters 
 as normal ones like `sliced(4, {allowDownsize: true})` and it 
 creates some maybe unnecessary overhead.
 However it is probably the easiest solution right now.

 What are your thoughts on this issue?

 On a side note: many templated functions are also complicated 
 and experiencing this issue, so it also might be worth to think 
 about this issue too ;-)

 Cheers,

 Seb

 [1] 
 http://forum.dlang.org/post/pxndhoskpjxvnoacajaz forum.dlang.org
 [2] https://github.com/DlangScience/mir/issues/18
 [3] 
 https://github.com/D-Programming-Language/phobos/pull/4041/files
 [4] 
 https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d


As far as I understand, the main two problems with named 
arguments are overloading ambiguity and the fact that argument 
names are not part of the signature. Using a struct to define the 
named arguments solves the signature problem, but the ambiguity 
problem remains - it simply gets shifted from "which overload to 
choose" to "which struct to choose".

The consensus here seems to be that ambiguous code should be 
result in compilation errors(and that it should be easy for the 
compiler to detect that the code is ambiguous!), and that if 
structs are used to declare named arguments, then solving 
overloading ambiguities should be done by constructing the struct 
explicitly. Then everyone disagree regarding how structs should 
be created explicitly with named fields.

I would like to suggest an idea that will allow solving 
ambiguities without the need for new syntax(behind the syntax for 
declaring and using named arguments), be consistent with existing 
D features, and as a bonus provide a much nicer syntax:


Make it like variadic functions!


Declaring the named arguments variadically will be done by adding 
`...` after a struct argument:

     struct Options{int x; int y=1; int z=2;}
     auto fun(Options options ...)

We'll need a syntax for specifying the arguments - but that's 
more of a matter of taste than an actual technical problem, and 
it's going to be bikeshedded over and over, so for the purpose of 
describing my idea let's pick a Ruby-style `:`(because `=` will 
break the rule of if-it-compiles-as-C-it-should-work-like-C):

     fun(x: 4, z: 3);

I've promised you to solve ambiguity, right? Well, just like 
regular variadic functions can be called with an explicit array, 
named arguments variadic functions should also be callable with 
an explicit struct:

     Options options = {x: 4, z: 3};
     fun(options);

Which brings us back to square one, right? Wrong! Because at this 
point, it should be trivial to give structs a second default 
constructor:

     this(typeof(this) that ...) {
         this = that;
     }

(actual implementation may be more efficient and 
robust(preferably a syntactic sugar for postblit), but you get 
the idea). So now structs can be constructed with named 
arguments, and ambiguities could be neatly solved with:

     fun(Options(x: 4, z: 3));



P.S: If a struct-based solution is ever implemented for named 
arguments, I do hope it'll support template inference, where a 
simple PODS(Plain Old D Struct... sorry...) is automatically 
created based on the supplied arguments' names and types(and 
order!). UDA support for that could be nice too...
Mar 08 2016
parent Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Tuesday, 8 March 2016 at 20:32:02 UTC, Idan Arye wrote:

 Declaring the named arguments variadically will be done by 
 adding `...` after a struct argument:

     struct Options{int x; int y=1; int z=2;}
     auto fun(Options options ...)

 We'll need a syntax for specifying the arguments - but that's 
 more of a matter of taste than an actual technical problem, and 
 it's going to be bikeshedded over and over, so for the purpose 
 of describing my idea let's pick a Ruby-style `:`(because `=` 
 will break the rule of 
 if-it-compiles-as-C-it-should-work-like-C):

     fun(x: 4, z: 3);

 I've promised you to solve ambiguity, right?


--snip--

I'm not sure, but I think the problem Walter has lies with 
_detecting_ ambiguity in the first place, because that would make 
overload resolution more complicated. I personally don't think 
it's that big a problem, because selecting the candidates could 
be a step before actual (= as it is now) overload resolution.
Mar 10 2016
prev sibling parent reply Edwin van Leeuwen <edder tkwsping.nl> writes:
On Sunday, 6 March 2016 at 17:35:38 UTC, Seb wrote:

 Hey all,

 Using structs is not ideal, because one can't require 
 parameters, but this can be solved by having those parameters 
 as normal ones like `sliced(4, {allowDownsize: true})` and it 
 creates some maybe unnecessary overhead.
 However it is probably the easiest solution right now.


In ggplotd I often use named tuples as and "anonymoous" struct:
Tuple!(double,"x")( 0.0 )

I also added a merge function that will return a tuple containing 
merged named tuples:

Tuple!(double,"x",string,"colour")(-1, 
"black").merge(Tuple!(double,"x")(0.0))

returns:
Tuple!(double,"x",string,"colour")(0, "black");

As an aside the merge function also works with structs so you can 
do the following:

struct Point
{
   double x;
   double y;
}

Tuple!(double,"x",string,"colour")(-1, "black").merge(Point(1,2))

returns:
Tuple!(double,"x",double,"y",string,"colour")(1, 2, "black");

It works reasonably well, except that the tuples require a lot of 
typing.
Mar 08 2016
next sibling parent Edwin van Leeuwen <edder tkwsping.nl> writes:
On Wednesday, 9 March 2016 at 07:30:31 UTC, Edwin van Leeuwen 
wrote:

 I also added a merge function that will return a tuple 
 containing merged named tuples:

 Tuple!(double,"x",string,"colour")(-1, 
 "black").merge(Tuple!(double,"x")(0.0))

 returns:
 Tuple!(double,"x",string,"colour")(0, "black");


Quick clarification. The merge function is used to merge the 
passed tuple, with the default values needed in the function. 
This way we don't have to worry about missing values.
Mar 08 2016
prev sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
On Wednesday, 9 March 2016 at 07:30:31 UTC, Edwin van Leeuwen 
wrote:

 On Sunday, 6 March 2016 at 17:35:38 UTC, Seb wrote:

 [...]


 In ggplotd I often use named tuples as and "anonymoous" struct:
 Tuple!(double,"x")( 0.0 )

 I also added a merge function that will return a tuple 
 containing merged named tuples:

 Tuple!(double,"x",string,"colour")(-1, 
 "black").merge(Tuple!(double,"x")(0.0))

 returns:
 Tuple!(double,"x",string,"colour")(0, "black");

 As an aside the merge function also works with structs so you 
 can do the following:

 struct Point
 {
   double x;
   double y;
 }

 Tuple!(double,"x",string,"colour")(-1, 
 "black").merge(Point(1,2))

 returns:
 Tuple!(double,"x",double,"y",string,"colour")(1, 2, "black");

 It works reasonably well, except that the tuples require a lot 
 of typing.


slightly tangentially, you might be interested in this: 
https://github.com/D-Programming-Language/phobos/pull/4043
Mar 09 2016