On 2013-03-24 20:59, timotheecour wrote:
>> BTW, why was the constructor added to Proxy and the "dummy" argument?
>
> because I wanted to simplify syntax from 'auto
> ret2=named!fun.z(3).x(4).call();' to 'auto
> ret2=named!fun.z(3).x(4)();'
> In doing that, I was having CT errors without it due to ambiguity
> between default unnamed constructor and opCall, so I added
> constructor.
> Then inside the named() function i needed to return a proxy object.
> Alternatives were:
> return Proxy!(func, null)(); //wrong: would call opCall
> return Proxy!(func, null).init; //not sure if it would incur overhead
> return Proxy!(func, null)(0); //introduces dummy arg, which should be
> optimized away.

Aha, ok I see.


> Finally, how do I reply from my email client ? Right I'm using
> http://forum.dlang.org/ otherwise the message isn't delivered on the
> forum... Thanks!

I'm using Thunderbird and just using "Reply to the message".

-- 
/Jacob Carlborg

> I'm using Thunderbird and just using "Reply to the message".


using gmail but doesn't work... (testing again via this message...) pls
ignore if this succeeds!

On 2013-03-24 23:53, a a wrote:

> using gmail but doesn't work... (testing again via this message...) pls
> ignore if this succeeds!

I got this.

-- 
/Jacob Carlborg

On Saturday, 23 March 2013 at 15:00:13 UTC, bearophile wrote:
> foobar:
>
>> Code that needs named parameters to be more readable is poorly designed code in the first place.
>
> Have you used a language where the usage of named arguments is idiomatic, like Python, Scala or Ada? They are sometimes useful even for well designed code, like functions with two arguments.
>
> Bye,
> bearophile

"idiomatic" is a relative term, tightly coupled to a specific language. Idiomatic D code for example is very different from idiomatic Haskell code.
Idiomatic Python style in D would be very unidiomatic D code and vise versa. Each language has its own conventions, styles, set of distinct features, etc, etc and trying to use "language A" style while coding in "language B" is like trying to fit a square peg in a round hole.
For instance, I would NOT use smalltalk naming conventions while writing say Java code. Both have very good and very consistent styles that are tightly coupled with their respective syntaxes and are very unsuitable to use in the other language.

In short, if you want to discuss python features, style or specific math plotting libraries, please post to the python mailing list, not D's NG.

On Saturday, 23 March 2013 at 15:59:12 UTC, Jacob Carlborg wrote:
> On 2013-03-23 16:55, John Colvin wrote:
>
>> A simple example is matplotlib.pyplot.plot
>>
>> There are so many possible flags and parameters that can be passed in
>> order to get the exact behaviour you want, but commonly you'll only want
>> a few set for each call. You don't want to have to set all the other
>> preceding parameters, you just want to go e.g. plot(data, linewidth=5)
>
> I've heard it was a big boost for C# when it got support for default arguments and named parameters. It made it a lot easier to integrate with COM.

AFAIK, this is only relevant or useful for COM (i.e. to support legacy, not really OO code) and is not supported (compile error?) for regular C# code as it is *not idiomatic C#* style (and is not OO).

foobar:

> "idiomatic" is a relative term, tightly coupled to a specific language. Idiomatic D code for example is very different from idiomatic Haskell code.
> Idiomatic Python style in D would be very unidiomatic D code and vise versa. Each language has its own conventions, styles, set of distinct features, etc, etc and trying to use "language A" style while coding in "language B" is like trying to fit a square peg in a round hole.
> For instance, I would NOT use smalltalk naming conventions while writing say Java code. Both have very good and very consistent styles that are tightly coupled with their respective syntaxes and are very unsuitable to use in the other language.
>
> In short, if you want to discuss python features, style or specific math plotting libraries, please post to the python mailing list, not D's NG.

Imperative/OOP languages are not totally different from each other, both Python and D derive strongly from C that comes partially from Algol, and D copies several things from Python (string functions, part of the module system, part of the range design comes from itertools, and so on). So comparing languages and their features is very useful.

If you have not used named arguments in languages that idiomatically use them, then it's not easy for you to see how and why they are sometimes useful and good.

In Python function arguments don't have a type, so named arguments are more useful than in D. But from my experience in Python, I believe D could enjoy named arguments.

Bye,
bearophile

On Monday, 25 March 2013 at 13:02:49 UTC, bearophile wrote:
> foobar:
>
>> "idiomatic" is a relative term, tightly coupled to a specific language. Idiomatic D code for example is very different from idiomatic Haskell code.
>> Idiomatic Python style in D would be very unidiomatic D code and vise versa. Each language has its own conventions, styles, set of distinct features, etc, etc and trying to use "language A" style while coding in "language B" is like trying to fit a square peg in a round hole.
>> For instance, I would NOT use smalltalk naming conventions while writing say Java code. Both have very good and very consistent styles that are tightly coupled with their respective syntaxes and are very unsuitable to use in the other language.
>>
>> In short, if you want to discuss python features, style or specific math plotting libraries, please post to the python mailing list, not D's NG.
>
> Imperative/OOP languages are not totally different from each other, both Python and D derive strongly from C that comes partially from Algol, and D copies several things from Python (string functions, part of the module system, part of the range design comes from itertools, and so on). So comparing languages and their features is very useful.
>
> If you have not used named arguments in languages that idiomatically use them, then it's not easy for you to see how and why they are sometimes useful and good.
>
> In Python function arguments don't have a type, so named arguments are more useful than in D. But from my experience in Python, I believe D could enjoy named arguments.
>
> Bye,
> bearophile

C is a HORRIBLE language regarding naming conventions and is a *very poor choice* to learn from in this regard. Python sets very high expectations regarding "beautiful code" and IMHO fails miserably (more so because of the starting higher expectations).
I admit to being spoiled by actually beautifully designed languages that are far superior in that respect. I suggest to learn Smalltalk for a language that emphasizes code readability decades before Python became cool.
I find Ruby which is based on Smalltalk's semantics and spirit to be more elegant and less pretentious compared to Python.

On 2013-03-21 19:35, J wrote:

[snip]

I just noticed that Michel Fortin has implemented basic support for named parameters. I've updated his code to the latest DMD and pushed it to my fork:

https://github.com/jacob-carlborg/dmd/commit/e363a093040c4b14e7e814027c3e199676c82820

From the commit message:

Add basic support for named parameters.

This will only allow to add the name of the parameter
when calling a function. It doesn't not support passing
the arguments out of order.

All credit goes to Michel Fortin.

-- 
/Jacob Carlborg

On Monday, 25 March 2013 at 16:03:38 UTC, Jacob Carlborg wrote:
> On 2013-03-21 19:35, J wrote:
>
> [snip]
>
> I just noticed that Michel Fortin has implemented basic support for named parameters. I've updated his code to the latest DMD and pushed it to my fork:
>
> https://github.com/jacob-carlborg/dmd/commit/e363a093040c4b14e7e814027c3e199676c82820
>
> From the commit message:
>
> Add basic support for named parameters.
>
> This will only allow to add the name of the parameter
> when calling a function. It doesn't not support passing
> the arguments out of order.
>
> All credit goes to Michel Fortin.

+1000

Excellent!

On Monday, 25 March 2013 at 18:11:54 UTC, J wrote:
> On Monday, 25 March 2013 at 16:03:38 UTC, Jacob Carlborg wrote:
>> On 2013-03-21 19:35, J wrote:
>>
>> [snip]
>>
>> I just noticed that Michel Fortin has implemented basic support for named parameters. I've updated his code to the latest DMD and pushed it to my fork:
>>
>> https://github.com/jacob-carlborg/dmd/commit/e363a093040c4b14e7e814027c3e199676c82820
>>
>> From the commit message:
>>
>> Add basic support for named parameters.
>>
>> This will only allow to add the name of the parameter
>> when calling a function. It doesn't not support passing
>> the arguments out of order.
>>
>> All credit goes to Michel Fortin.
>
> +1000
>
> Excellent!

Wow. This is really nice!  I added a method to Michel's nice work. You can get it in this branch.

https://github.com/glycerine/dmd/tree/namedarg

All the dmd test suite then passes.

You can now do this:

void test (double y, double z, int a, int b, int c, string d) { }

void main ()
{
    test(y: 33.3,
         z: 44.4,
         a: 9999,
         b: 8888,
            7777,   // truly optional
         d:"Yehaw");
}


I also tested the passing of named parameters through variadic templates, and there is a little work needed to make them 'named argument' aware. I added a failing test for that, if anyone wants to tackle it.  It is dmd/test/compilable/namedarg_vararg.d in the branch above.

$ cat namedarg_vararg.d
cat namedarg_vararg.d
import core.vararg;
import std.stdio;

void test(A...)(A a)
{
    foreach(t; a)
        writeln(t);
}

void main ()
{
    test(x:33.3,
         z: 44.4,
         a: 9999,
         b: 8888,
         7777,
         d:"Yehaw");
}

$ dmd namedarg_vararg.d
namedarg_vararg.d(12): Error: template namedarg_vararg.test(A...)(A a) cannot deduce template function from argument types !()(x:double,z:double,a:int,b:int,int,d:string)
$

 * * *

Wierd and cool: Since the current version requires the exact same positions as names, it is almost like you get extra refined type safety for free.  Say I have a function that takes two strings. The compiler can now help me if I mistakenly switch the two...

Example:

void find(string needle, string haystack) { }
void main ()
{
    find(haystack: "abcdefg",
           needle: "def");
}

dmd can now helpfully point out:

namedarg_haystack.d(6): Error: function namedarg_haystack.find (string needle, string haystack) is not callable using argument types (haystack:string,needle:string)

Nice.  This has a different feel to it than where the compiler just 'makes it right' for you, but I still really like it. Super readable.