#!/usr/bin/rdmd
void main(string[] arg) {
// Observation: I'd like to say:
/*
auto r = myfunc.call("named") with { z= 2; x = -123; y = 200; }
*/
// and have it turned into this:
with(myfunc) { x = -123; y = 200; z = -20; }
auto r = myfunc.call("named");
// Q: is there some way t
// CORRECTION:
// and have it turned into this:
with(myfunc) { z =2; x = -123; y = 200; }
auto r = myfunc.call("named");
/* Similarly but different (here I am instantiating a new
struct
before the call, rather than re-using a global single
struct each time),
it would be lovely and elegant to say:
*/
void main(string[] arg) {
/* Elegant:
auto r = myfunc() with { z= 2; x = -123; y = 200; }
On 2013-03-21 19:35, J wrote:
Here's another workaround:
https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135
--
/Jacob Carlborg
Jacob Carlborg:
Here's another workaround:
https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135
Maybe such two links should go in one page of the D wiki about
lack of named parameters workarounds.
Eventually D should introduce a syntax for named arguments at the
On Thursday, 21 March 2013 at 19:59:01 UTC, Jacob Carlborg wrote:
On 2013-03-21 19:35, J wrote:
Here's another workaround:
https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135
Intriguing, Jacob! I could learn alot about reflection by
studying your code.
How is
On 2013-03-21 21:33, bearophile wrote:
Maybe such two links should go in one page of the D wiki about lack of
named parameters workarounds.
Eventually D should introduce a syntax for named arguments at the call
point plus a syntax to deprecate argument names. It's not the most
important thing t
On 2013-03-21 21:42, J wrote:
Intriguing, Jacob! I could learn alot about reflection by studying your
code.
How is it installed? I installing by downloading that single file, and
with a quick hack to the Reflection.d top three lines (commenting out
the module and imports at the top), I tried
Jacob Carlborg:
What do you think about my suggestion for anonymous structs as
named parameters?
You show code like:
void foo ({ int x, int y } point)
{
}
foo({ y: 5, x: 3 });
D already has two kinds of tuples so I don't want a "third kind"
of tuple. What I want is D to manage better the
On 2013-03-21 22:18, bearophile wrote:
You show code like:
void foo ({ int x, int y } point)
{
}
foo({ y: 5, x: 3 });
D already has two kinds of tuples so I don't want a "third kind" of
tuple. What I want is D to manage better the Phobos Tuple we already
have, adding an unpacking syntax
(htt
The bigger point here is more profound: it is trivial to
implement named parameters using structs + trivial lowerings, and
this is no way conflicts with function overloading.
D deserves to have named parameters to functions -- it makes for
much more legible code, and obviates the need for sl
With credit for inspiration to David Medlock in this post--
http://forum.dlang.org/thread/d9lnrr$26q3$1...@digitaldaemon.com ...
// Tongue firmly in cheek, I'd like to introduce
// the NAPAPISS principle: (with apologies to SFINAE and RAII)
// NAPAPISS = NAmed Parameters Are simply Passed in a
On 2013-03-22 11:17, J wrote:
With credit for inspiration to David Medlock in this post--
http://forum.dlang.org/thread/d9lnrr$26q3$1...@digitaldaemon.com ...
// Tongue firmly in cheek, I'd like to introduce
// the NAPAPISS principle: (with apologies to SFINAE and RAII)
// NAPAPISS = NAmed Para
On Friday, 22 March 2013 at 09:18:33 UTC, J wrote:
The bigger point here is more profound: it is trivial to
implement named parameters using structs + trivial lowerings,
and this is no way conflicts with function overloading.
D deserves to have named parameters to functions -- it makes
for
http://dlang.org/phobos/std_traits.html#.ParameterIdentifierTuple
On Friday, 22 March 2013 at 15:50:38 UTC, Dicebot wrote:
http://dlang.org/phobos/std_traits.html#.ParameterIdentifierTuple
Seems to me like a solved problem.
so i hacked up a working solution yesterday.
advantages over
https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135:
no need to no arguments at CT (just names); allows optional and
non optional ones; allows return value; also, mambo depends on
tango and is hard to revi
On Friday, 22 March 2013 at 18:48:56 UTC, timotheecour wrote:
so i hacked up a working solution yesterday.
advantages over
https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135:
no need to no arguments at CT (just names); allows optional and
non optional ones; allows
22-Mar-2013 23:03, deadalnix пишет:
On Friday, 22 March 2013 at 18:48:56 UTC, timotheecour wrote:
so i hacked up a working solution yesterday.
advantages over
https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135:
no need to no arguments at CT (just names); allows opt
On Friday, 22 March 2013 at 10:17:02 UTC, J wrote:
With credit for inspiration to David Medlock in this post--
http://forum.dlang.org/thread/d9lnrr$26q3$1...@digitaldaemon.com
...
// Tongue firmly in cheek, I'd like to introduce
// the NAPAPISS principle: (with apologies to SFINAE and RAII)
/
On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:
On Friday, 22 March 2013 at 10:17:02 UTC, J wrote:
With credit for inspiration to David Medlock in this post--
http://forum.dlang.org/thread/d9lnrr$26q3$1...@digitaldaemon.com
...
// Tongue firmly in cheek, I'd like to introduce
// the N
On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:
On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:
WTF? What do kwargs have to do with programming? Sounds more
like a half-Klingon & half-Ferengi species to me.
kwargs = keyword arguments
It's a common naming convention in p
On Friday, 22 March 2013 at 21:29:46 UTC, foobar wrote:
On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:
On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:
WTF? What do kwargs have to do with programming? Sounds more
like a half-Klingon & half-Ferengi species to me.
kwargs
auto s=callNamed!(fun,`x,y`)(10,20);
Thanks, but this is a non-solution.
The name must be next to the value ( x=10, y=20), so they it will
scale from 2 to 7 to 17 arguments and maintain readability.
On Saturday, 23 March 2013 at 05:43:22 UTC, J wrote:
auto s=callNamed!(fun,`x,y`)(10,20);
Thanks, but this is a non-solution.
The name must be next to the value ( x=10, y=20), so they it
will scale from 2 to 7 to 17 arguments and maintain readability.
For a use case, compare this call
refl
On Friday, 22 March 2013 at 21:41:46 UTC, John Colvin wrote:
On Friday, 22 March 2013 at 21:29:46 UTC, foobar wrote:
On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:
On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:
WTF? What do kwargs have to do with programming? Sounds mor
On Saturday, 23 March 2013 at 08:20:19 UTC, J wrote:
On Saturday, 23 March 2013 at 05:43:22 UTC, J wrote:
auto s=callNamed!(fun,`x,y`)(10,20);
Thanks, but this is a non-solution.
The name must be next to the value ( x=10, y=20), so they it
will scale from 2 to 7 to 17 arguments and maintain
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 argumen
On 2013-03-22 21:02, Dmitry Olshansky wrote:
Can opDispatch & chaining be leveraged to get the effect of:
named!(fun).x(10).y(20).call();
Here you go:
http://pastebin.com/ALaXLgt3
Use that together with "callNamed" from timotheecour.
--
/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 usefu
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
On Saturday, 23 March 2013 at 15:55:36 UTC, John Colvin wrote:
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
On Saturday, 23 March 2013 at 19:56:17 UTC, deadalnix wrote:
On Saturday, 23 March 2013 at 15:55:36 UTC, John Colvin wrote:
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.
I updated
https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d
to incorporate Jacob Carlborg's idea (thanks for the
working+clean code! let me know if attribution is ok)
auto a=named!fun.z(3).x(4).call();
and then simplified it a bit to:
auto a=named!fun.z(3).x(4)();
It
> It's now looking pretty close to the ideal D syntax:
> auto a=fun(z:3,x:4);
The last time I tried this (maybe 2 years ago, so before
std.traits.ParameterNameTuple?), I used associative arrays:
alias nfoo = named!foo; // nfoo is now a function admitting AA as arguments
auto result = nfoo(["z":"
On 2013-03-24 03:05, timotheecour wrote:
I updated
https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d
to incorporate Jacob Carlborg's idea (thanks for the working+clean code!
let me know if attribution is ok)
Absolutely.
If 'fun(z:3,x:4)' syntax later comes to D, it'd
On 2013-03-24 09:13, Philippe Sigaud wrote:
Also, I see that at one time, you used a full string syntax:
auto result = nfoo(q{z = "Title", x = 1, y = 100}); // nfoo will parse
the input string
I rather like this one. Why did you ditch it?
That would requires compile time values, i.e. no vari
On Sun, Mar 24, 2013 at 11:15 AM, Jacob Carlborg wrote:
>> auto result = nfoo(q{z = "Title", x = 1, y = 100}); // nfoo will parse
>> the input string
>>
>> I rather like this one. Why did you ditch it?
>
> That would requires compile time values, i.e. no variables.
You're right.
On 2013-03-24 03:05, timotheecour wrote:
I updated
https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d
to incorporate Jacob Carlborg's idea (thanks for the working+clean code!
let me know if attribution is ok)
BTW, why was the constructor added to Proxy and the "dummy" a
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 o
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
> 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 usefu
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
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 distin
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.
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
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/
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
On Monday, 25 March 2013 at 16:03:38 UTC, Jacob Carlborg wrote:
[cut]
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.
Interesting
On 2013-03-26 10:31, renoX wrote:
Interesting, the "doesn't not support passing the arguments out of
order." can be seen either as a (temporary or not) implementation
limitation OR as a feature.
I would guess it was easier. At least the change is very small. Smaller
that I would have imagined
On Tuesday, 26 March 2013 at 09:31:53 UTC, renoX wrote:
The things to check is how this feature would work with
optional parameters..
Another thing to check is whether there is enough information in
the object files to link across separately compiled objects.
Correct me if I'm wrong, but I d
On Tuesday, 26 March 2013 at 20:28:39 UTC, J wrote:
On Tuesday, 26 March 2013 at 09:31:53 UTC, renoX wrote:
The things to check is how this feature would work with
optional parameters..
Another thing to check is whether there is enough information
in the object files to link across separately
On Tuesday, 26 March 2013 at 12:14:08 UTC, Jacob Carlborg wrote:
On 2013-03-26 10:31, renoX wrote:
Interesting, the "doesn't not support passing the arguments
out of
order." can be seen either as a (temporary or not)
implementation
limitation OR as a feature.
I would guess it was easier. At
>>Interesting, the "doesn't not support passing the arguments out of order."
>>can be seen either as a (temporary or not) implementation >>limitation OR as
>>a feature.
Named parameters are only interesting if we can skip some optional parameters.
This allows the python-like syntax of specifying
On Wednesday, 27 March 2013 at 03:29:24 UTC, Timothee Cour wrote:
Named parameters are only interesting if we can skip some
optional parameters.
This allows the python-like syntax of specifying only a subset
of
parameters; otherwise this isn't very interesting. This is used
heavily in python an
On Wednesday, 27 March 2013 at 03:29:24 UTC, Timothee Cour wrote:
Interesting, the "doesn't not support passing the arguments
out of order." can be seen either as a (temporary or not)
implementation >>limitation OR as a feature.
Named parameters are only interesting if we can skip some
option
58 matches
Mail list logo
