www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pretty please: Named arguments

reply Bekenn <leaveme alone.com> writes:
Consider the following line from a project I'm playing around with:

	HRESULT hr = m_Device.Present(null, null, null, null);

Quick: What behavior does that third argument specify?  If you said, 
"Well, /obviously/, that's a handle to an alternative destination window 
for the render operation; by passing null, you're choosing not to 
provide an alternative render target." then... well, gee, I have no 
answer to that.

With named arguments, it becomes a bit easier to understand:

	HRESULT hr = m_Device.Present(pSourceRect: null, pDestRect: null, 
hDestWindowOverride: null, pDirtyRegion: null);

If I remember right, Python has this (optional) feature; I'm not aware 
of anyone ever complaining about it.  It also nicely provides a solution 
to the bool argument problem: 
http://blogs.msdn.com/b/oldnewthing/archive/2006/08/28/728349.aspx

But wait, there's more!

Named arguments get a +1 synergy bonus with default arguments.  When 
using parameter names to specify arguments, the order in which those 
arguments are passed no longer matters.  Imagine if the Present() method 
above provided the default argument null for each parameter:

interface IDirect3DDevice9 : IUnknown
{
	...
	HRESULT Present(const(RECT)* pSourceRect = null, const(RECT)* pDestRect 
= null, HWND hDestWindowOverride = null, const(RGNDATA)* pDirtyRegion = 
null);
	...
}

We can do this in the D binding without running afoul of any linkage 
issues, and it simplifies the Present() call for its most common usage, 
which I think is a good thing.  Now, let's say I'm doing something 
special; suppose I'm not worried about source and destination rectangles 
or dirty regions, but I do want to supply a different render target. 
With named arguments, that's easy to do without making things messy:

	HRESULT hr = m_Device.Present(hDestWindowOverride: hOverride);

Named arguments should also play nicely with positional arguments:

	auto wrappedString = wrap(reallyLongString, colmuns: 120, tabsize: 4);

Lastly, wouldn't be an entirely new feature; D already supports named 
arguments for static struct initializers.  I merely propose sharing the 
love with normal functions and struct literals.

Here are the rules I have in mind:

1) Named arguments are not a replacement for positional arguments. 
Arguments fall into three categories: positional, named positional, and 
named non-positional.  An argument is positional if no name is supplied. 
  An argument is named positional if a name is supplied and its position 
matches the parameter's position in the function declaration.  An 
argument is named non-positional if a name is supplied and either a) its 
position does not match the parameter's position in the function 
declaration, or b) it is immediately preceded by a named non-positional 
argument.

2) No positional argument may appear after a named non-positional argument.

3) Named non-positional arguments may appear in any order.


Potential problems:  The only problems I can foresee here are variations 
on the situation when there are two (or more) versions of a function 
with the same number, type, and names of parameters, but in non-matching 
order, like this:

void func(int a, char b);
void func(char b, int a);

In such a case, the compiler should diagnose an error if named arguments 
are employed.

Thoughts?
Feb 27 2011
next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Sun, 2011-02-27 at 23:03 -0800, Bekenn wrote:
[ . . . ]
 If I remember right, Python has this (optional) feature; I'm not aware=
=20
 of anyone ever complaining about it.  It also nicely provides a solution=
=20
 to the bool argument problem:=20
 http://blogs.msdn.com/b/oldnewthing/archive/2006/08/28/728349.aspx
=20
 But wait, there's more!
=20
 Named arguments get a +1 synergy bonus with default arguments.  When=20
 using parameter names to specify arguments, the order in which those=20
 arguments are passed no longer matters.  Imagine if the Present() method=
=20
 above provided the default argument null for each parameter:
Pythons parameter passing system is fantastic: the combination of positional parameters, keyword arguments, default values, "rest of positionals", "rest of keyword arguments" means that handling C and C++ libraries where many functions/methods have many parameters (some of the graphics libraries have functions with 10s of parameters) far easier than using C or C++ directly. It is no surprise to me that the scientific community is taking to the Python/C/C++ combination in droves. Python is a great coordination and top-level UI language leaving the grunt computation to C and C++ -- well to be honest there is a huge amount of Fortran as well. It is clear to me that most of the "Big Science" codes need a rewrite, but it just isn't going to happen, so for all "number crunching" that doesn't involve brand new codes, interfacing to C, C++ and Fortran is mandatory. It should be noted that the Python parameter passing only works as beautifully as it does because everything in Python is handled with dictionaries (aka maps).=20 [ . . . ]
 1) Named arguments are not a replacement for positional arguments.=20
 Arguments fall into three categories: positional, named positional, and=
=20
 named non-positional.  An argument is positional if no name is supplied.=
=20
   An argument is named positional if a name is supplied and its position=
=20
 matches the parameter's position in the function declaration.  An=20
 argument is named non-positional if a name is supplied and either a) its=
=20
 position does not match the parameter's position in the function=20
 declaration, or b) it is immediately preceded by a named non-positional=
=20
 argument.
=20
 2) No positional argument may appear after a named non-positional argumen=
t.
=20
 3) Named non-positional arguments may appear in any order.
Or just pick up the Python approach in its entirety? The huge downside of any named parameter approach is that you have data coupling between the source of the callee and the caller. This is fine in a language such as Python where you distribute source and documentation tools so you can always find out the names of parameters, this is going to be a bit of a problem in languages where only the compiled form may be the only distributed form. Programmers rely on some other form of documentation other than the source and this leads to error,
 Potential problems:  The only problems I can foresee here are variations=
=20
 on the situation when there are two (or more) versions of a function=20
 with the same number, type, and names of parameters, but in non-matching=
=20
 order, like this:
=20
 void func(int a, char b);
 void func(char b, int a);
=20
 In such a case, the compiler should diagnose an error if named arguments=
=20
 are employed.
=20
 Thoughts?
The Python mechanism relies on the fact that despatch is by name and not by signature. Languages that dispatch by signature will have significantly greater problems!=20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 27 2011
next sibling parent reply Bekenn <leaveme alone.com> writes:
On 2/27/2011 11:32 PM, Russel Winder wrote:
 The Python mechanism relies on the fact that despatch is by name and not
 by signature.  Languages that dispatch by signature will have
 significantly greater problems!
I don't follow; the compiler has to look up the correct function signature whether you use named arguments or not. How is this significantly different?
Feb 27 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 27 February 2011 23:40:41 Bekenn wrote:
 On 2/27/2011 11:32 PM, Russel Winder wrote:
 The Python mechanism relies on the fact that despatch is by name and not
 by signature.  Languages that dispatch by signature will have
 significantly greater problems!
I don't follow; the compiler has to look up the correct function signature whether you use named arguments or not. How is this significantly different?
You could be linking to code where you don't _have_ the source and don't _have_ the names of the variables. It's all done by the function signature in C, C++, calling the function, and so any linkers that follow C conventions (as with happens with D) _must_ be able to deal with function calls based on their signatures. That doesn't necessarily mean that it would be _impossible_ to find a way to have named arguments in D, but it makes it _far_ harder. - Jonathna M Davis
Feb 28 2011
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Mon, 28 Feb 2011 10:04:31 +0200, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Sunday 27 February 2011 23:40:41 Bekenn wrote:
 On 2/27/2011 11:32 PM, Russel Winder wrote:
 The Python mechanism relies on the fact that despatch is by name and  
not
 by signature.  Languages that dispatch by signature will have
 significantly greater problems!
I don't follow; the compiler has to look up the correct function signature whether you use named arguments or not. How is this significantly different?
You could be linking to code where you don't _have_ the source and don't _have_ the names of the variables. It's all done by the function signature in C, C++, calling the function, and so any linkers that follow C conventions (as with happens with D) _must_ be able to deal with function calls based on their signatures. That doesn't necessarily mean that it would be _impossible_ to find a way to have named arguments in D, but it makes it _far_ harder.
I don't see the problem here. Either mangle the argument names (just as C++ and D mangle argument types), or just ignore this problem completely and use the parameter names in the function declaration. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Feb 28 2011
prev sibling parent reply Bekenn <leaveme alone.com> writes:
On 2/28/2011 12:04 AM, Jonathan M Davis wrote:
 You could be linking to code where you don't _have_ the source and don't _have_
 the names of the variables. It's all done by the function signature in C, C++,

 calling the function, and so any linkers that follow C conventions (as with
 happens with D) _must_ be able to deal with function calls based on their
 signatures. That doesn't necessarily mean that it would be _impossible_ to
find a
 way to have named arguments in D, but it makes it _far_ harder.

 - Jonathna M Davis
Again, I don't see why that's a problem; you can't call a function if you don't have a function declaration somewhere (perhaps in a .di file). The compiler would do parameter name lookup based on the current module's view of the function space. If you truly don't have a declaration, then that means you're calling through a function pointer or a delegate. Again, no problem: either a) the function pointer or the delegate specifies names for the arguments, or b) it doesn't, in which case you simply can't use named arguments. I'm absolutely not suggesting that parameter names should be part of the ABI, nor am I suggesting that function declarations must present parameter names; if names aren't available to the module at compile time, then you can't use named arguments. Where's the problem?
Feb 28 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/28/11 2:22 AM, Bekenn wrote:
 On 2/28/2011 12:04 AM, Jonathan M Davis wrote:
 You could be linking to code where you don't _have_ the source and
 don't _have_
 the names of the variables. It's all done by the function signature in
 C, C++,

 calling the function, and so any linkers that follow C conventions (as
 with
 happens with D) _must_ be able to deal with function calls based on their
 signatures. That doesn't necessarily mean that it would be
 _impossible_ to find a
 way to have named arguments in D, but it makes it _far_ harder.

 - Jonathna M Davis
Again, I don't see why that's a problem; you can't call a function if you don't have a function declaration somewhere (perhaps in a .di file). The compiler would do parameter name lookup based on the current module's view of the function space. If you truly don't have a declaration, then that means you're calling through a function pointer or a delegate. Again, no problem: either a) the function pointer or the delegate specifies names for the arguments, or b) it doesn't, in which case you simply can't use named arguments. I'm absolutely not suggesting that parameter names should be part of the ABI, nor am I suggesting that function declarations must present parameter names; if names aren't available to the module at compile time, then you can't use named arguments. Where's the problem?
I don't see any. One more thing, order of evaluation should still be left-to-right, not in order of arguments. This means the feature cannot be a syntactic rewrite (not a big issue, but definitely something to keep in mind). Andrei
Feb 28 2011
next sibling parent reply Bekenn <leaveme alone.com> writes:
On 2/28/11 5:48 AM, Andrei Alexandrescu wrote:
 One more thing, order of evaluation should still be left-to-right, not
 in order of arguments. This means the feature cannot be a syntactic
 rewrite (not a big issue, but definitely something to keep in mind).


 Andrei
I was thinking that order of evaluation should remain lexically left-to-right at the point of call (that is, in the order the arguments are specified, with any remaining default parameters coming after); is there a reason that would be bad or wouldn't work?
Feb 28 2011
next sibling parent Jim <bitcirkel yahoo.com> writes:
Bekenn Wrote:

 On 2/28/11 5:48 AM, Andrei Alexandrescu wrote:
 One more thing, order of evaluation should still be left-to-right, not
 in order of arguments. This means the feature cannot be a syntactic
 rewrite (not a big issue, but definitely something to keep in mind).


 Andrei
I was thinking that order of evaluation should remain lexically left-to-right at the point of call (that is, in the order the arguments are specified, with any remaining default parameters coming after); is there a reason that would be bad or wouldn't work?
No, the called function could be from a linked library, for all we know. Reordering the evaluation of the arguments would not have any effect on the function itself. Left-to-right evaluation at the point of call would concur with the Principle of Least Astonishment: void fun(int foo, int bar); int moo(); // might have side-effects! fun(bar:moo(), foo:moo());
Feb 28 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/28/11 12:38 PM, Bekenn wrote:
 On 2/28/11 5:48 AM, Andrei Alexandrescu wrote:
 One more thing, order of evaluation should still be left-to-right, not
 in order of arguments. This means the feature cannot be a syntactic
 rewrite (not a big issue, but definitely something to keep in mind).


 Andrei
I was thinking that order of evaluation should remain lexically left-to-right at the point of call (that is, in the order the arguments are specified, with any remaining default parameters coming after); is there a reason that would be bad or wouldn't work?
I meant the same as you. Andrei
Feb 28 2011
parent reply spir <denis.spir gmail.com> writes:
On 03/01/2011 02:36 AM, Andrei Alexandrescu wrote:
 On 2/28/11 12:38 PM, Bekenn wrote:
 On 2/28/11 5:48 AM, Andrei Alexandrescu wrote:
 One more thing, order of evaluation should still be left-to-right, not
 in order of arguments. This means the feature cannot be a syntactic
 rewrite (not a big issue, but definitely something to keep in mind).


 Andrei
I was thinking that order of evaluation should remain lexically left-to-right at the point of call (that is, in the order the arguments are specified, with any remaining default parameters coming after); is there a reason that would be bad or wouldn't work?
I meant the same as you.
I agree with this. Keeping order makes things simpler, probably helps implementation of the feature (I guess), and removes nearly nothing imo. Named params are about helping reading code. On the other hand, I would like it still be possible to write: void f (x=0, y=0) {...} ... f(y=1); This is unorderd strictly speaking... (Sorry for my possibly wrong English) Denis -- _________________ vita es estrany spir.wikidot.com
Mar 01 2011
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 01/03/2011 11:59, spir wrote:
<snip>
 On the other hand, I would like it still be possible to write:
 void f (x=0, y=0) {...}
 ...
 f(y=1);
<snip> It would. And it would still set the variable y in the calling scope to 1, and then call f(1, 0). Stewart.
Mar 02 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 One more thing, order of evaluation should still be left-to-right, not 
 in order of arguments. This means the feature cannot be a syntactic 
 rewrite (not a big issue, but definitely something to keep in mind).
In this case then I suggest the compiler to just refuse the compilation of that line of code. Better to disallow something than allowing something that breaks one of the (future!) D rules. Bye, bearophile
Feb 28 2011
prev sibling parent Russel Winder <russel russel.org.uk> writes:
On Sun, 2011-02-27 at 23:40 -0800, Bekenn wrote:
 On 2/27/2011 11:32 PM, Russel Winder wrote:
 The Python mechanism relies on the fact that despatch is by name and no=
t
 by signature.  Languages that dispatch by signature will have
 significantly greater problems!
=20 I don't follow; the compiler has to look up the correct function=20 signature whether you use named arguments or not. How is this=20 significantly different?
In C, C++ and D yes, in Python despatch is only by function name, not by signature -- exactly because of the parameter passing mechanism. Put it another way, Python does not have function overloading. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 28 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/28/11 1:32 AM, Russel Winder wrote:
 The huge downside of any named parameter approach is that you have data
 coupling between the source of the callee and the caller.  This is fine
 in a language such as Python where you distribute source and
 documentation tools so you can always find out the names of parameters,
 this is going to be a bit of a problem in languages where only the
 compiled form may be the only distributed form.  Programmers rely on
 some other form of documentation other than the source and this leads to
 error,
It's not all that bad. Walter and I discussed a couple of times adding such a feature. As long as the function signature in the .d or .di file does specify a parameter name, that can be used.
 Potential problems:  The only problems I can foresee here are variations
 on the situation when there are two (or more) versions of a function
 with the same number, type, and names of parameters, but in non-matching
 order, like this:

 void func(int a, char b);
 void func(char b, int a);

 In such a case, the compiler should diagnose an error if named arguments
 are employed.

 Thoughts?
The Python mechanism relies on the fact that despatch is by name and not by signature. Languages that dispatch by signature will have significantly greater problems!
A good subset of Python's approach to parameter passing sugar can be done without using maps or dispatch by name. Andrei
Feb 28 2011
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Russel Winder <russel russel.org.uk> wrote:

 The Python mechanism relies on the fact that despatch is by name and not
 by signature.  Languages that dispatch by signature will have
 significantly greater problems!
Hardly. Just like with default arguments, the compiler would add in the missing stuff and use the simple signature. The parameter names would not be part of the signature. -- Simen
Feb 28 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/28/2011 08:03 AM, Bekenn wrote:
 Consider the following line from a project I'm playing around with:

 HRESULT hr = m_Device.Present(null, null, null, null);

 Quick: What behavior does that third argument specify? If you said, "Well,
 /obviously/, that's a handle to an alternative destination window for the
 render operation; by passing null, you're choosing not to provide an
 alternative render target." then... well, gee, I have no answer to that.

 With named arguments, it becomes a bit easier to understand:

 HRESULT hr = m_Device.Present(pSourceRect: null, pDestRect: null,
 hDestWindowOverride: null, pDirtyRegion: null);

 If I remember right, Python has this (optional) feature; I'm not aware of
 anyone ever complaining about it. It also nicely provides a solution to the
 bool argument problem:
 http://blogs.msdn.com/b/oldnewthing/archive/2006/08/28/728349.aspx

 But wait, there's more!

 Named arguments get a +1 synergy bonus with default arguments. When using
 parameter names to specify arguments, the order in which those arguments are
 passed no longer matters. Imagine if the Present() method above provided the
 default argument null for each parameter:

 interface IDirect3DDevice9 : IUnknown
 {
 ...
 HRESULT Present(const(RECT)* pSourceRect = null, const(RECT)* pDestRect = null,
 HWND hDestWindowOverride = null, const(RGNDATA)* pDirtyRegion = null);
 ...
 }

 We can do this in the D binding without running afoul of any linkage issues,
 and it simplifies the Present() call for its most common usage, which I think
 is a good thing. Now, let's say I'm doing something special; suppose I'm not
 worried about source and destination rectangles or dirty regions, but I do want
 to supply a different render target. With named arguments, that's easy to do
 without making things messy:

 HRESULT hr = m_Device.Present(hDestWindowOverride: hOverride);

 Named arguments should also play nicely with positional arguments:

 auto wrappedString = wrap(reallyLongString, colmuns: 120, tabsize: 4);

 Lastly, wouldn't be an entirely new feature; D already supports named arguments
 for static struct initializers. I merely propose sharing the love with normal
 functions and struct literals.

 Here are the rules I have in mind:

 1) Named arguments are not a replacement for positional arguments. Arguments
 fall into three categories: positional, named positional, and named
 non-positional. An argument is positional if no name is supplied. An argument
 is named positional if a name is supplied and its position matches the
 parameter's position in the function declaration. An argument is named
 non-positional if a name is supplied and either a) its position does not match
 the parameter's position in the function declaration, or b) it is immediately
 preceded by a named non-positional argument.

 2) No positional argument may appear after a named non-positional argument.

 3) Named non-positional arguments may appear in any order.


 Potential problems: The only problems I can foresee here are variations on the
 situation when there are two (or more) versions of a function with the same
 number, type, and names of parameters, but in non-matching order, like this:

 void func(int a, char b);
 void func(char b, int a);

 In such a case, the compiler should diagnose an error if named arguments are
 employed.

 Thoughts?
I'm all for a feature of named arguments. I consider it a _base_ feature D is sadly lacking for the moment. Unlike tons of other issues, it is not a rare, weird, or sophisticated request. Thus, it should have the highest priority once 64-bit support has reached a workable state. There does not seem to be any feature requests for this on the issue tracker. On the other hand, this feature may be very simple and still handy: either all args are named, or none. E basta! Denis -- _________________ vita es estrany spir.wikidot.com
Feb 28 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 02/28/2011 08:32 AM, Russel Winder wrote:
 Thoughts?
The Python mechanism relies on the fact that despatch is by name and not by signature. Languages that dispatch by signature will have significantly greater problems!
The Python system also has a weak point: confusion of 'optional' and 'default' notions. These are 2 orthogonal aspects python forces you to mess up. There are optional args with no default values, and mandatory ones with defaults. If you want to define an optional arg, python wants you to "invent" a fake default value. This is bad --even more in that it tends to load 'None'(common choice for fake value) with application semantics. Denis -- _________________ vita es estrany spir.wikidot.com
Feb 28 2011
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-02-28 02:03:46 -0500, Bekenn <leaveme alone.com> said:

 Potential problems:  The only problems I can foresee here are 
 variations on the situation when there are two (or more) versions of a 
 function with the same number, type, and names of parameters, but in 
 non-matching order, like this:
 
 void func(int a, char b);
 void func(char b, int a);
 
 In such a case, the compiler should diagnose an error if named 
 arguments are employed.
 
 Thoughts?
Another problem is what happens if you override a function by using different parameter names. For instance: class A { void func(int foo); } class B : A { void func(int bar); } Currently, the above is allowed. Would it now become an error? I think it'd be much easier to support named arguments if we didn't allow reordering. I know I'm stripping the proposal from one of its main benefits, but I think the essence remains. This would make the rather common pattern of adding a comment for each argument compiler-verifiable without disrupting things too much: draw(null, // text null, // font 12, // size 0, // flags ); draw(text: null, font: null, size: 12, flags: 0); It would be implemented as a check for equality of the argument names after overload resolution. No ABI change, no interaction with overloading, just an extra check that if an argument name is specified it must match the one in the declaration. There'd still be a funny interaction with overriding (see my first example), but you can always leave your argument unnamed if the definition keep changing the name in unpredictable ways. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 28 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Feb 2011 07:41:06 -0500, Michel Fortin  
<michel.fortin michelf.com> wrote:

 On 2011-02-28 02:03:46 -0500, Bekenn <leaveme alone.com> said:

 Potential problems:  The only problems I can foresee here are  
 variations on the situation when there are two (or more) versions of a  
 function with the same number, type, and names of parameters, but in  
 non-matching order, like this:
  void func(int a, char b);
 void func(char b, int a);
  In such a case, the compiler should diagnose an error if named  
 arguments are employed.
  Thoughts?
Another problem is what happens if you override a function by using different parameter names. For instance: class A { void func(int foo); } class B : A { void func(int bar); } Currently, the above is allowed. Would it now become an error? I think it'd be much easier to support named arguments if we didn't allow reordering. I know I'm stripping the proposal from one of its main benefits, but I think the essence remains. This would make the rather common pattern of adding a comment for each argument compiler-verifiable without disrupting things too much: draw(null, // text null, // font 12, // size 0, // flags ); draw(text: null, font: null, size: 12, flags: 0); It would be implemented as a check for equality of the argument names after overload resolution. No ABI change, no interaction with overloading, just an extra check that if an argument name is specified it must match the one in the declaration. There'd still be a funny interaction with overriding (see my first example), but you can always leave your argument unnamed if the definition keep changing the name in unpredictable ways.
All these 'what if' ambiguities are simple to resolve -- if you use positional arguments, it works. If you use named arguments, and it matches more than one overload, it fails. In fact, the case you give is unambiguous -- if you have an A, you can use foo, if you have a B, you can use bar. Note that the confusion is all to the person, and is completely avoidable. It's like naming your arguments xy234m5 -- nobody knows what that means, so just choose a better name. But it's not illegal. I would say this would be a huge improvement to D. But I would also say from my recollection, Walter is very against this. I think it would take a motivated developer creating a pull request to get it done... -Steve
Feb 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 I would say this would be a huge improvement to D.  But I would also say  
  from my recollection, Walter is very against this.  I think it would take  
 a motivated developer creating a pull request to get it done...
request is the tuple unpacking syntax, another thing that's useful all the time). They are present in some languages as Python. Or in Ada language, where they are named "named arguments": http://en.wikibooks.org/wiki/Ada_Programming/Subprograms#Named_parameters http://msdn.microsoft.com/en-us/library/dd264739.aspx http://geekswithblogs.net/michelotti/archive/2009/01/22/c-4.0-named-parameters-for-bett r-code-quality.aspx ) If you use named arguments in Python, you learn how much useful they are, I use them often. They don't increase much the complexity of the language for the programmer, they make code less bug-prone, more handy to write, and more self-annotated with compiled-verified annotations. You have a function like: void drawRectangle(int height, int width) {...} You call it with: drawRectangle(640, 480); But you may be wrong, having inverted the two values: drawRectangle(480, 640); With good named argument you remove that bug source: drawRectangle(width: 640, height: 480); Named arguments are so useful that they justify little changes in the compiler too, if necessary. Bye, bearophile
Feb 28 2011
parent Bekenn <leaveme alone.com> writes:
On 2/28/11 5:11 AM, bearophile wrote:

 http://msdn.microsoft.com/en-us/library/dd264739.aspx
 http://geekswithblogs.net/michelotti/archive/2009/01/22/c-4.0-named-parameters-for-bett
r-code-quality.aspx  )
Looking through that first link, it looks like their rules are very nearly a match for what I came up with; the only difference I can see is that they'd prohibit the use of positional arguments following a named argument (even if the named argument is in the expected position). My argument in favor of named positional arguments (after which you *can* continue to specify positional arguments) is that the name becomes a compiler-verified annotation.
Feb 28 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 02/28/2011 01:41 PM, Michel Fortin wrote:
 On 2011-02-28 02:03:46 -0500, Bekenn <leaveme alone.com> said:

 Potential problems: The only problems I can foresee here are variations on
 the situation when there are two (or more) versions of a function with the
 same number, type, and names of parameters, but in non-matching order, like
 this:

 void func(int a, char b);
 void func(char b, int a);

 In such a case, the compiler should diagnose an error if named arguments are
 employed.

 Thoughts?
Another problem is what happens if you override a function by using different parameter names. For instance: class A { void func(int foo); } class B : A { void func(int bar); } Currently, the above is allowed. Would it now become an error? I think it'd be much easier to support named arguments if we didn't allow reordering. I know I'm stripping the proposal from one of its main benefits, but I think the essence remains. This would make the rather common pattern of adding a comment for each argument compiler-verifiable without disrupting things too much: draw(null, // text null, // font 12, // size 0, // flags ); draw(text: null, font: null, size: 12, flags: 0); It would be implemented as a check for equality of the argument names after overload resolution. No ABI change, no interaction with overloading, just an extra check that if an argument name is specified it must match the one in the declaration.
+++ Make things simple! Since positional arguments is the main & historic parameter-passing method, just keep order. For me, allowing unordered arguments is just a (somewhat nice) side-effect of naming. The huge gain by far is "semantic unload" talen out of programmer shoulders ; and self-documentation. Just like in your example. The latter point (self-doc) also has a big benefit in terms of language learning: if code samples use named args, then understanding and memorising common funcs and other tools can be far easier.
 There'd still be a funny interaction with overriding (see my first example),
 but you can always leave your argument unnamed if the definition keep changing
 the name in unpredictable ways.
I would say: name mismatch --> error. Meaning "x.func(foo=1)" throws if method lookup ends up selecting "B.func" (meaning x is a B); conversely "x.func(bar=1)" throws if method lookup ends up selecting "A.func" (meaning x is an A but not a B). Denis -- _________________ vita es estrany spir.wikidot.com
Feb 28 2011
parent reply Bekenn <leaveme alone.com> writes:
On 2/28/11 5:59 AM, spir wrote:
 +++ Make things simple!
 Since positional arguments is the main & historic parameter-passing
 method, just keep order.
I think that would remove a huge chunk of the utility of having named arguments, and it doesn't make things easier at all from the compiler's perspective. Consider: Declaration: void func(int a = 0, int b = 1); Call: func(b: 3); // a is default Since b in the call is not in the same position as specified in the declaration (position 0 instead of position 1), the compiler already has to ignore the positioning of named arguments.
Feb 28 2011
parent spir <denis.spir gmail.com> writes:
On 02/28/2011 08:01 PM, Bekenn wrote:
 On 2/28/11 5:59 AM, spir wrote:
 +++ Make things simple!
 Since positional arguments is the main & historic parameter-passing
 method, just keep order.
I think that would remove a huge chunk of the utility of having named arguments, and it doesn't make things easier at all from the compiler's perspective. Consider: Declaration: void func(int a = 0, int b = 1); Call: func(b: 3); // a is default Since b in the call is not in the same position as specified in the declaration (position 0 instead of position 1), the compiler already has to ignore the positioning of named arguments.
Yes, you are right on this. But it's because there is a confusion between default and optional parameter, no? Denis -- _________________ vita es estrany spir.wikidot.com
Feb 28 2011
prev sibling parent Bekenn <leaveme alone.com> writes:
On 2/28/11 4:41 AM, Michel Fortin wrote:
 Another problem is what happens if you override a function by using
 different parameter names. For instance:

 class A {
 void func(int foo);
 }
 class B : A {
 void func(int bar);
 }

 Currently, the above is allowed. Would it now become an error?
Definitely not an error! This feature should not break any existing code. Method lookup already happens based on the static type of your object reference; that shouldn't change: A a = new A; a.func(foo = 3); // ok a.func(bar = 3); // Error, argument name does not match parameter name B b = new B; b.func(foo = 3); // Error, argument name does not match parameter name b.func(bar = 3); // ok A c = new B; c.func(foo = 3); // ok c.func(bar = 3); // Error
Feb 28 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I prefer using the equals sign:
foo(action = "dofoo", times = 100)

This is how Python does it.
Feb 28 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Feb 2011 07:48:24 -0500, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 I prefer using the equals sign:
 foo(action = "dofoo", times = 100)

 This is how Python does it.
This syntax already means something in D: string action; int times; foo(action = "dofoo", times = 100); // set action to "dofoo" and times to 100 and pass those to the function. -Steve
Feb 28 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/28/11, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 This syntax already means something in D:

 string action;
 int times;
 foo(action = "dofoo", times = 100); // set action to "dofoo" and times to
 100 and pass those to the function.

 -Steve
Except that doesn't do what you'd expect it to do: void foo(ref int time) { } void main() { int times; foo(times = 100); // set times to 100 and pass to the function. } Error: function test.foo (ref int time) is not callable using argument types (int) Error: times = 100 is not an lvalue
Feb 28 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Feb 2011 08:15:02 -0500, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 On 2/28/11, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 This syntax already means something in D:

 string action;
 int times;
 foo(action = "dofoo", times = 100); // set action to "dofoo" and times  
 to
 100 and pass those to the function.

 -Steve
Except that doesn't do what you'd expect it to do: void foo(ref int time) { } void main() { int times; foo(times = 100); // set times to 100 and pass to the function. }
When I said "pass those" I meant "pass those values". I was not assuming ref arguments. In any case, your syntax for named arguments is not possible. x = y is an expression, and can be used anywhere an expression can be used. -Steve
Feb 28 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/28/11, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 In any case, your syntax for named arguments is not possible.  x = y is an
 expression, and can be used anywhere an expression can be used.
I agree. I'm thinking there would be more ambiguity with the Python syntax: void foo(int value = 50) { } void main() { int value = 20; foo(value=40); // does main.value change? }
Feb 28 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Would named arguments work with compile-time/template arguments as well?
Feb 28 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 02/28/2011 02:01 PM, Steven Schveighoffer wrote:
 On Mon, 28 Feb 2011 07:48:24 -0500, Andrej Mitrovic
 <andrej.mitrovich gmail.com> wrote:

 I prefer using the equals sign:
 foo(action = "dofoo", times = 100)

 This is how Python does it.
This syntax already means something in D: string action; int times; foo(action = "dofoo", times = 100); // set action to "dofoo" and times to 100 and pass those to the function.
This is *very* bad imo. But since it's inherited from C we cannot change it (acoording to D design principles). So, let's use ':'. Denis -- _________________ vita es estrany spir.wikidot.com
Feb 28 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-02-28 09:34:30 -0500, spir <denis.spir gmail.com> said:

 So, let's use ':'.
Note however that ':' already has a meaning in templates arguments. Using ':' for named function arguments would preclude having named template arguments (or force template arguments to use yet another syntax). -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 28 2011
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-02-28 09:55:54 -0500, Michel Fortin <michel.fortin michelf.com> said:

 On 2011-02-28 09:34:30 -0500, spir <denis.spir gmail.com> said:
 
 So, let's use ':'.
Note however that ':' already has a meaning in templates arguments. Using ':' for named function arguments would preclude having named template arguments (or force template arguments to use yet another syntax).
Oops, sorry. I was mixing up template definition and template instanciation. Turns out there's no real problem: template Test(T : U) { } Test!(T: int); -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 28 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Feb 2011 09:55:54 -0500, Michel Fortin  
<michel.fortin michelf.com> wrote:

 On 2011-02-28 09:34:30 -0500, spir <denis.spir gmail.com> said:

 So, let's use ':'.
Note however that ':' already has a meaning in templates arguments. Using ':' for named function arguments would preclude having named template arguments (or force template arguments to use yet another syntax).
I think you are confusing template declarations with template instantiations. ':' is not used in instantiations (that I know of) e.g. the usage would be: template foo(T = int, U = string) {...} foo!(U : int)...; -Steve
Feb 28 2011
parent spir <denis.spir gmail.com> writes:
On 02/28/2011 04:02 PM, Steven Schveighoffer wrote:
 On Mon, 28 Feb 2011 09:55:54 -0500, Michel Fortin <michel.fortin michelf.com>
 wrote:

 On 2011-02-28 09:34:30 -0500, spir <denis.spir gmail.com> said:

 So, let's use ':'.
Note however that ':' already has a meaning in templates arguments. Using ':' for named function arguments would preclude having named template arguments (or force template arguments to use yet another syntax).
I think you are confusing template declarations with template instantiations. ':' is not used in instantiations (that I know of) e.g. the usage would be: template foo(T = int, U = string) {...} foo!(U : int)...;
Yes, but the semantic conflict remains: on left hand, subtyping; on right hand plain naming. Denis -- _________________ vita es estrany spir.wikidot.com
Feb 28 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 02/28/2011 03:55 PM, Michel Fortin wrote:
 On 2011-02-28 09:34:30 -0500, spir <denis.spir gmail.com> said:

 So, let's use ':'.
Note however that ':' already has a meaning in templates arguments. Using ':' for named function arguments would preclude having named template arguments (or force template arguments to use yet another syntax).
Yes, I'm aware of that. This usage in fact conflicts with the general "subtyping" semantics of ':'. But this conflict already exists with the usage of ':' in dyn array notation, which is linguistically pretty close to a named argument set; so... Denis -- _________________ vita es estrany spir.wikidot.com
Feb 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
spir:

 Yes, I'm aware of that. This usage in fact conflicts with the general 
 "subtyping" semantics of ':'. But this conflict already exists with the usage 
 of ':' in dyn array notation, which is linguistically pretty close to a named 
 argument set; so...
If I have understood what you mean here, then I think we'll just have to leave with this small clash. An alternative solution is to use the Ada syntax: foo(x => 1, y=>2) but it's a bit longer because it requires two chars instead of one. Bye, bearophile
Feb 28 2011
parent reply spir <denis.spir gmail.com> writes:
On 02/28/2011 07:56 PM, bearophile wrote:
 spir:

 Yes, I'm aware of that. This usage in fact conflicts with the general
 "subtyping" semantics of ':'. But this conflict already exists with the usage
 of ':' in dyn array notation, which is linguistically pretty close to a named
 argument set; so...
If I have understood what you mean here, then I think we'll just have to leave with this small clash. An alternative solution is to use the Ada syntax: foo(x => 1, y=>2) but it's a bit longer because it requires two chars instead of one.
Agreed, and I'm not for adding non-obvious "signs". D is not Perl. Or else use ':=' ? Denis -- _________________ vita es estrany spir.wikidot.com
Feb 28 2011
next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
spir <denis.spir gmail.com> wrote:

 Agreed, and I'm not for adding non-obvious "signs". D is not Perl. Or  
 else use ':=' ?
:= is acceptable to me. It does not clash with anything, and clearly shows that something is being set to something. -- Simen
Feb 28 2011
prev sibling parent reply Bekenn <leaveme alone.com> writes:
On 2/28/11 11:53 AM, spir wrote:
 Agreed, and I'm not for adding non-obvious "signs". D is not Perl. Or
 else use ':=' ?

 Denis
I think we should stick with ':' due to its existing use in static struct initializers.
Feb 28 2011
parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Bekenn <leaveme alone.com> wrote:

 On 2/28/11 11:53 AM, spir wrote:
 Agreed, and I'm not for adding non-obvious "signs". D is not Perl. Or
 else use ':=' ?

 Denis
I think we should stick with ':' due to its existing use in static struct initializers.
Seconded. -- Simen
Feb 28 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/28/11, spir <denis.spir gmail.com> wrote:
 But this conflict already exists with the
 usage
 of ':' in dyn array notation
Wait, when is ':' used with dynamic arrays?
Feb 28 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Feb 2011 14:32:52 -0500, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 On 2/28/11, spir <denis.spir gmail.com> wrote:
 But this conflict already exists with the
 usage
 of ':' in dyn array notation
Wait, when is ':' used with dynamic arrays?
Think he meant AA. -Steve
Feb 28 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 02/28/2011 08:39 PM, Steven Schveighoffer wrote:
 On Mon, 28 Feb 2011 14:32:52 -0500, Andrej Mitrovic
 <andrej.mitrovich gmail.com> wrote:

 On 2/28/11, spir <denis.spir gmail.com> wrote:
 But this conflict already exists with the
 usage
 of ':' in dyn array notation
Wait, when is ':' used with dynamic arrays?
Think he meant AA.
You're right, Steve. Sorry, distraction... Denis -- _________________ vita es estrany spir.wikidot.com
Feb 28 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-02-28 20:39, Steven Schveighoffer wrote:
 On Mon, 28 Feb 2011 14:32:52 -0500, Andrej Mitrovic
 <andrej.mitrovich gmail.com> wrote:

 On 2/28/11, spir <denis.spir gmail.com> wrote:
 But this conflict already exists with the
 usage
 of ':' in dyn array notation
Wait, when is ':' used with dynamic arrays?
Think he meant AA. -Steve
Or static arrays. -- /Jacob Carlborg
Feb 28 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/28/11 6:48 AM, Andrej Mitrovic wrote:
 I prefer using the equals sign:
 foo(action = "dofoo", times = 100)

 This is how Python does it.
// in a module far, far away void fun(double x); // In a module importing it int x = 42; fun(x = 43); Andrei
Feb 28 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/28/11, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 On 2/28/11 6:48 AM, Andrej Mitrovic wrote:
 I prefer using the equals sign:
 foo(action = "dofoo", times = 100)

 This is how Python does it.
// in a module far, far away void fun(double x); // In a module importing it int x = 42; fun(x = 43); Andrei
Yes, I've mentioned I was wrong in my next-to-last post. :)
Feb 28 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/28/11 8:16 AM, Andrej Mitrovic wrote:
 On 2/28/11, Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:
 On 2/28/11 6:48 AM, Andrej Mitrovic wrote:
 I prefer using the equals sign:
 foo(action = "dofoo", times = 100)

 This is how Python does it.
// in a module far, far away void fun(double x); // In a module importing it int x = 42; fun(x = 43); Andrei
Yes, I've mentioned I was wrong in my next-to-last post. :)
Apologies - I replied to posts this morning as I was seeing them, a practice I need to change. Andrei
Feb 28 2011
prev sibling parent reply Bekenn <leaveme alone.com> writes:
On 2/28/11 4:48 AM, Andrej Mitrovic wrote:
 I prefer using the equals sign:
 foo(action = "dofoo", times = 100)

 This is how Python does it.
I went with : because that's what's already used in static struct initializers.
Feb 28 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/28/11, Bekenn <leaveme alone.com> wrote:
 I went with : because that's what's already used in static struct
 initializers.
I even forgot about those! It's also used in static arrays and static unions.
Feb 28 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-02-28 08:03, Bekenn wrote:
 Consider the following line from a project I'm playing around with:

 HRESULT hr = m_Device.Present(null, null, null, null);

 Quick: What behavior does that third argument specify? If you said,
 "Well, /obviously/, that's a handle to an alternative destination window
 for the render operation; by passing null, you're choosing not to
 provide an alternative render target." then... well, gee, I have no
 answer to that.

 With named arguments, it becomes a bit easier to understand:

 HRESULT hr = m_Device.Present(pSourceRect: null, pDestRect: null,
 hDestWindowOverride: null, pDirtyRegion: null);

 If I remember right, Python has this (optional) feature; I'm not aware
 of anyone ever complaining about it. It also nicely provides a solution
 to the bool argument problem:
 http://blogs.msdn.com/b/oldnewthing/archive/2006/08/28/728349.aspx

 But wait, there's more!

 Named arguments get a +1 synergy bonus with default arguments. When
 using parameter names to specify arguments, the order in which those
 arguments are passed no longer matters. Imagine if the Present() method
 above provided the default argument null for each parameter:

 interface IDirect3DDevice9 : IUnknown
 {
 ...
 HRESULT Present(const(RECT)* pSourceRect = null, const(RECT)* pDestRect
 = null, HWND hDestWindowOverride = null, const(RGNDATA)* pDirtyRegion =
 null);
 ...
 }

 We can do this in the D binding without running afoul of any linkage
 issues, and it simplifies the Present() call for its most common usage,
 which I think is a good thing. Now, let's say I'm doing something
 special; suppose I'm not worried about source and destination rectangles
 or dirty regions, but I do want to supply a different render target.
 With named arguments, that's easy to do without making things messy:

 HRESULT hr = m_Device.Present(hDestWindowOverride: hOverride);

 Named arguments should also play nicely with positional arguments:

 auto wrappedString = wrap(reallyLongString, colmuns: 120, tabsize: 4);

 Lastly, wouldn't be an entirely new feature; D already supports named
 arguments for static struct initializers. I merely propose sharing the
 love with normal functions and struct literals.

 Here are the rules I have in mind:

 1) Named arguments are not a replacement for positional arguments.
 Arguments fall into three categories: positional, named positional, and
 named non-positional. An argument is positional if no name is supplied.
 An argument is named positional if a name is supplied and its position
 matches the parameter's position in the function declaration. An
 argument is named non-positional if a name is supplied and either a) its
 position does not match the parameter's position in the function
 declaration, or b) it is immediately preceded by a named non-positional
 argument.

 2) No positional argument may appear after a named non-positional argument.

 3) Named non-positional arguments may appear in any order.


 Potential problems: The only problems I can foresee here are variations
 on the situation when there are two (or more) versions of a function
 with the same number, type, and names of parameters, but in non-matching
 order, like this:

 void func(int a, char b);
 void func(char b, int a);

 In such a case, the compiler should diagnose an error if named arguments
 are employed.

 Thoughts?
It's possible to implement this as a library: http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135 Not a complete solution but it works. -- /Jacob Carlborg
Feb 28 2011
parent reply Bekenn <leaveme alone.com> writes:
On 2/28/11 5:05 AM, Jacob Carlborg wrote:
 It's possible to implement this as a library:
 http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135

 Not a complete solution but it works.
That has scary syntax; no thanks.
Feb 28 2011
parent "Nick Sabalausky" <a a.a> writes:
"Bekenn" <leaveme alone.com> wrote in message 
news:ikgs96$9in$3 digitalmars.com...
 On 2/28/11 5:05 AM, Jacob Carlborg wrote:
 It's possible to implement this as a library:
 http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135

 Not a complete solution but it works.
That has scary syntax; no thanks.
It is a pretty gnarly syntax. And it doesn't support return values, and the arg values are mixed into the wrong context. But it's a hell of a lot better than nothing: calling certain functions without using named arguments scares the shit out of me. I think I'll probably use it (or something like it) on funcs that really need it. One thing that could help is if it was modified slightly to work like this: ---------------------- int foo(int a, int b) {...} // We need better string-mixin syntax!!!! auto x = mixin( namedArgs(q{ foo(a=10,b=27) }) ); // Turns into --> auto x = foo(10,27); ---------------------- If we could ever manage to get string-producing CTFEs that are implicitly mixed-in, which we desparately need anyway, then that would be: ---------------------- auto x = namedArgs(q{ foo(a=10,b=27) }); ---------------------- Which I think would be a perfectly acceptable stop-gap solution until we can get *real* named arguments.
Feb 28 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, February 27, 2011 23:03:46 Bekenn wrote:
 Consider the following line from a project I'm playing around with:
 
 	HRESULT hr = m_Device.Present(null, null, null, null);
 
 Quick: What behavior does that third argument specify?  If you said,
 "Well, /obviously/, that's a handle to an alternative destination window
 for the render operation; by passing null, you're choosing not to
 provide an alternative render target." then... well, gee, I have no
 answer to that.
 
 With named arguments, it becomes a bit easier to understand:
 
 	HRESULT hr = m_Device.Present(pSourceRect: null, pDestRect: null,
 hDestWindowOverride: null, pDirtyRegion: null);
 
 If I remember right, Python has this (optional) feature; I'm not aware
 of anyone ever complaining about it.  It also nicely provides a solution
 to the bool argument problem:
 http://blogs.msdn.com/b/oldnewthing/archive/2006/08/28/728349.aspx
 
 But wait, there's more!
 
 Named arguments get a +1 synergy bonus with default arguments.  When
 using parameter names to specify arguments, the order in which those
 arguments are passed no longer matters.  Imagine if the Present() method
 above provided the default argument null for each parameter:
 
 interface IDirect3DDevice9 : IUnknown
 {
 	...
 	HRESULT Present(const(RECT)* pSourceRect = null, const(RECT)* pDestRect
 = null, HWND hDestWindowOverride = null, const(RGNDATA)* pDirtyRegion =
 null);
 	...
 }
 
 We can do this in the D binding without running afoul of any linkage
 issues, and it simplifies the Present() call for its most common usage,
 which I think is a good thing.  Now, let's say I'm doing something
 special; suppose I'm not worried about source and destination rectangles
 or dirty regions, but I do want to supply a different render target.
 With named arguments, that's easy to do without making things messy:
 
 	HRESULT hr = m_Device.Present(hDestWindowOverride: hOverride);
 
 Named arguments should also play nicely with positional arguments:
 
 	auto wrappedString = wrap(reallyLongString, colmuns: 120, tabsize: 4);
 
 Lastly, wouldn't be an entirely new feature; D already supports named
 arguments for static struct initializers.  I merely propose sharing the
 love with normal functions and struct literals.
 
 Here are the rules I have in mind:
 
 1) Named arguments are not a replacement for positional arguments.
 Arguments fall into three categories: positional, named positional, and
 named non-positional.  An argument is positional if no name is supplied.
   An argument is named positional if a name is supplied and its position
 matches the parameter's position in the function declaration.  An
 argument is named non-positional if a name is supplied and either a) its
 position does not match the parameter's position in the function
 declaration, or b) it is immediately preceded by a named non-positional
 argument.
 
 2) No positional argument may appear after a named non-positional argument.
 
 3) Named non-positional arguments may appear in any order.
 
 
 Potential problems:  The only problems I can foresee here are variations
 on the situation when there are two (or more) versions of a function
 with the same number, type, and names of parameters, but in non-matching
 order, like this:
 
 void func(int a, char b);
 void func(char b, int a);
 
 In such a case, the compiler should diagnose an error if named arguments
 are employed.
 
 Thoughts?
I'm not entirely against named arguments being in D, however I do think that any functions that actually need them should be refactored anyway. So, ultimately, I'm not sure that they're really all that useful. I'm sure that they'd be useful upon occasion, but if you actually need them, then your function is taking too many arguments. In actuality, if I were to vote on whether named arguments should be in the language, I would definitely vote against it (I just plain don't want the code clutter, and they strike me as a crutch to avoid writing functions with good signatures in spite of their usefulness in some situations), but I can see why some people might want them. - Jonathan M Davis
Feb 28 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Feb 2011 13:51:56 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 I'm not entirely against named arguments being in D, however I do think  
 that any
 functions that actually need them should be refactored anyway. So,  
 ultimately,
 I'm not sure that they're really all that useful. I'm sure that they'd  
 be useful
 upon occasion, but if you actually need them, then your function is  
 taking too
 many arguments.

 In actuality, if I were to vote on whether named arguments should be in  
 the
 language, I would definitely vote against it (I just plain don't want  
 the code
 clutter, and they strike me as a crutch to avoid writing functions with  
 good
 signatures in spite of their usefulness in some situations), but I can  
 see why
 some people might want them.
Although I am not strongly for named arguments, I think they would be a definite improvement. Bearophile brought up one of the strongest cases for them: foo(int width, int height) {} Seems simple enough, I don't see how you have "too many arguments", but the call looks like this: foo(123, 456); So, looking at this call, can you tell which is width and which is height? I've seen some libs that use width and height do height first also. I usually have to go look up the API every time I'm reading/writing one of these. But this is perfectly clear and resists API changes/differences: foo(width: 123, height: 456); The cool part about this is, named arguments are not required -- you can always just not use them. But when you do use them, the code becomes much clearer. -Steve
Feb 28 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, February 28, 2011 11:02:37 Steven Schveighoffer wrote:
 On Mon, 28 Feb 2011 13:51:56 -0500, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:
 I'm not entirely against named arguments being in D, however I do think
 that any
 functions that actually need them should be refactored anyway. So,
 ultimately,
 I'm not sure that they're really all that useful. I'm sure that they'd
 be useful
 upon occasion, but if you actually need them, then your function is
 taking too
 many arguments.
 
 In actuality, if I were to vote on whether named arguments should be in
 the
 language, I would definitely vote against it (I just plain don't want
 the code
 clutter, and they strike me as a crutch to avoid writing functions with
 good
 signatures in spite of their usefulness in some situations), but I can
 see why
 some people might want them.
Although I am not strongly for named arguments, I think they would be a definite improvement. Bearophile brought up one of the strongest cases for them: foo(int width, int height) {} Seems simple enough, I don't see how you have "too many arguments", but the call looks like this: foo(123, 456); So, looking at this call, can you tell which is width and which is height? I've seen some libs that use width and height do height first also. I usually have to go look up the API every time I'm reading/writing one of these. But this is perfectly clear and resists API changes/differences: foo(width: 123, height: 456); The cool part about this is, named arguments are not required -- you can always just not use them. But when you do use them, the code becomes much clearer.
That does have some minimal benefit, but if you're really passing around width and height much, then I'd argue that they should be put in a struct rather than passed around bare like that, and then that fixes the issue. - Jonathan M Davis
Feb 28 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Feb 2011 14:33:55 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Monday, February 28, 2011 11:02:37 Steven Schveighoffer wrote:
 On Mon, 28 Feb 2011 13:51:56 -0500, Jonathan M Davis  
 <jmdavisProg gmx.com>

 wrote:
 I'm not entirely against named arguments being in D, however I do  
think
 that any
 functions that actually need them should be refactored anyway. So,
 ultimately,
 I'm not sure that they're really all that useful. I'm sure that they'd
 be useful
 upon occasion, but if you actually need them, then your function is
 taking too
 many arguments.

 In actuality, if I were to vote on whether named arguments should be  
in
 the
 language, I would definitely vote against it (I just plain don't want
 the code
 clutter, and they strike me as a crutch to avoid writing functions  
with
 good
 signatures in spite of their usefulness in some situations), but I can
 see why
 some people might want them.
Although I am not strongly for named arguments, I think they would be a definite improvement. Bearophile brought up one of the strongest cases for them: foo(int width, int height) {} Seems simple enough, I don't see how you have "too many arguments", but the call looks like this: foo(123, 456); So, looking at this call, can you tell which is width and which is height? I've seen some libs that use width and height do height first also. I usually have to go look up the API every time I'm reading/writing one of these. But this is perfectly clear and resists API changes/differences: foo(width: 123, height: 456); The cool part about this is, named arguments are not required -- you can always just not use them. But when you do use them, the code becomes much clearer.
That does have some minimal benefit, but if you're really passing around width and height much, then I'd argue that they should be put in a struct rather than passed around bare like that, and then that fixes the issue.
foo(dimensions(123, 456)); // not helping -Steve
Feb 28 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, February 28, 2011 11:37:04 Steven Schveighoffer wrote:
 On Mon, 28 Feb 2011 14:33:55 -0500, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:
 On Monday, February 28, 2011 11:02:37 Steven Schveighoffer wrote:
 On Mon, 28 Feb 2011 13:51:56 -0500, Jonathan M Davis
 <jmdavisProg gmx.com>
 
 wrote:
 I'm not entirely against named arguments being in D, however I do
think
 that any
 functions that actually need them should be refactored anyway. So,
 ultimately,
 I'm not sure that they're really all that useful. I'm sure that they'd
 be useful
 upon occasion, but if you actually need them, then your function is
 taking too
 many arguments.
 
 In actuality, if I were to vote on whether named arguments should be
in
 the
 language, I would definitely vote against it (I just plain don't want
 the code
 clutter, and they strike me as a crutch to avoid writing functions
with
 good
 signatures in spite of their usefulness in some situations), but I can
 see why
 some people might want them.
Although I am not strongly for named arguments, I think they would be a definite improvement. Bearophile brought up one of the strongest cases for them: foo(int width, int height) {} Seems simple enough, I don't see how you have "too many arguments", but the call looks like this: foo(123, 456); So, looking at this call, can you tell which is width and which is height? I've seen some libs that use width and height do height first also. I usually have to go look up the API every time I'm reading/writing one of these. But this is perfectly clear and resists API changes/differences: foo(width: 123, height: 456); The cool part about this is, named arguments are not required -- you can always just not use them. But when you do use them, the code becomes much clearer.
That does have some minimal benefit, but if you're really passing around width and height much, then I'd argue that they should be put in a struct rather than passed around bare like that, and then that fixes the issue.
foo(dimensions(123, 456)); // not helping
Like, I said if you're passing around the width and height much (as opposed to just once), then it definitely helps. But it doesn't necessarily help at the point of construction, so if you're just passing them to one function, then you don't really benefit. Still, I don't think that an example like this one makes the feature pulls its weight. Regardless, there are obviously a lot of people who like the idea, so if they can get Walter's support, it'll likely go in. I'd just as soon that it didn't, but it's not like it's my decision, and unless all the people who dislike it are silent or haven't read this thread, it definitely looks like the majority of folks around here are in favor of it. - Jonathan M Davis
Feb 28 2011
prev sibling next sibling parent Tomek =?ISO-8859-2?B?U293afFza2k=?= <just ask.me> writes:
Steven Schveighoffer napisa=B3:

 Although I am not strongly for named arguments, I think they would be a =
=20
 definite improvement.
=20
 Bearophile brought up one of the strongest cases for them:
=20
 foo(int width, int height) {}
=20
 Seems simple enough, I don't see how you have "too many arguments", but =
=20
 the call looks like this:
=20
 foo(123, 456);
=20
 So, looking at this call, can you tell which is width and which is =20
 height?  I've seen some libs that use width and height do height first =20
 also.  I usually have to go look up the API every time I'm reading/writin=
g =20
 one of these.
=20
 But this is perfectly clear and resists API changes/differences:
=20
 foo(width: 123, height: 456);
=20
 The cool part about this is, named arguments are not required -- you can =
=20
 always just not use them.  But when you do use them, the code becomes muc=
h =20
 clearer.
The classic beneficiary of named parameters is the widely understood user i= nterface. Presentation code (layout, formatting, graphics) is naturally awa= sh in options and switches. Take construction of std.format.FormatSpec as a next-door example. --=20 Tomek
Feb 28 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/28/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 but if you're really passing around
 width
 and height much, then I'd argue that they should be put in a struct rather
 than
 passed around bare like that, and then that fixes the issue.
But then you're back to square one: void foo(Size size) { } struct Size { int width, height; } void main() { auto size = Size(10, 20); // so what is 10 and what is 20? foo(size); }
Feb 28 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
 But then you're back to square one
Obviously, you'd do: Size size; size.width = 10; size.height = 20; Instead of Size(10, 20). Another alternative is to give each element their own struct... struct Width { int width; alias width this; } foo(Width(10), Height(20));
Feb 28 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Another alternative is to introduce named arguments and get rid of
that extra housekeeping.
Feb 28 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Feb 2011 14:56:15 -0500, Adam Ruppe <destructionator gmail.com>  
wrote:

 But then you're back to square one
Obviously, you'd do: Size size; size.width = 10; size.height = 20; Instead of Size(10, 20).
I could also do: int width = 10, height = 20; foo(width, height); The struct solution helps prevent incorrect ordering. But other than that, it still looks more verbose than should be necessary.
 Another alternative is to give each element their own struct...

 struct Width { int width; alias width this; }

 foo(Width(10), Height(20));
This seems like extreme overkill. I don't want to have to create a new struct for every parameter that I want to pass in a named fashion. Why can't we just pass integers where integers make sense, and give them names that only exist at compile time? I don't see the harm in the proposal. Certainly every counter proposal I've seen to be able to "accomplish the same thing" with today's compiler is worse than just passing two ints. -Steve
Feb 28 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
Steven Schveighoffer:
 But other than that, it still looks more verbose than should be
 necessary.
This is the real problem. We already have named arguments in today's D. You can do some stringof magic to get the parameter names and ParameterTypeTuple to assign them. I haven't written it, but there should be no blocker in combining these: void foo(int width, int height); auto args = NamedParameterTypeTuple!(foo); args.width = 10; args.height = 20; foo(args); But, that's just like the struct for length of code... If someone wanted to write the code to add the foo(width:10, height:10), I wouldn't likely object to it's inclusion. But, I don't see it as a big deal.
Feb 28 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-02-28 21:44, Adam Ruppe wrote:
 Steven Schveighoffer:
 But other than that, it still looks more verbose than should be
 necessary.
This is the real problem. We already have named arguments in today's D. You can do some stringof magic to get the parameter names and ParameterTypeTuple to assign them. I haven't written it, but there should be no blocker in combining these: void foo(int width, int height); auto args = NamedParameterTypeTuple!(foo); args.width = 10; args.height = 20; foo(args); But, that's just like the struct for length of code... If someone wanted to write the code to add the foo(width:10, height:10), I wouldn't likely object to it's inclusion. But, I don't see it as a big deal.
http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135 -- /Jacob Carlborg
Feb 28 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
And maybe sometimes you just want to update one field, e.g.:

void resize(int width=0, int height=0)
{
    if (width)
        // set new width
    if (height)
        // set new height
}

void main()
{
    resize(width:20, height:40);
    // more code..

    resize(width:50);  // only update width
}

Using a struct could potentially introduce bugs, e.g.:
void resize(Size size) { // this.size = size.. }
void main()
{
    Size size;
    size.width = 20;
    size.height = 40;
    resize(size);

    // more code
    size.width = 50;
    resize(size);
}

What if between the two calls to resize some other part of code has
manipulated the height? The size struct still has its height member
set to 40. So (for example) your window might suddenly jump in height
even though the user has updated only the width field.

Now you have to do extra housekeeping to keep things in order (e.g.
resetting the height field of the struct so the call to resize doesn't
touch the window height).
Feb 28 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Adam Ruppe:

 Size size;
 size.width = 10;
 size.height = 20;
 
 Instead of Size(10, 20).
This adds more clutter compared to argument names and requires more lines...
 Another alternative is to give each element their own struct...
 
 struct Width { int width; alias width this; }
 
 foo(Width(10), Height(20));
Time ago in D there was typedef for this. There are many problems with this solution: - You can't use this to give the arguments in a different order, or specify only part of the default arguments. - this can't be used with functions written by other people that don't already use structs for arguments - This forces you to always use those names at the calling point, while named arguments are usually optional at the calling point. - you need to define a new struct for each argument you may want to call with a name, this requires code and increases binary size for nothing. - Maybe there are problems with padding, like if the wrapped argument is an array ubyte[5]. - I think currently alias this is not fully transparent Bye, bearophile
Feb 28 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Also the resize method would have to look similar to the first one, I
messed that up, it should be:

void resize(Size size)
{
     if (size.width)
         this.width = size.width;
     if (size.height)
         this.height = size.height;
}
Feb 28 2011
prev sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Adam Ruppe <destructionator gmail.com> wrote:

 Another alternative is to give each element their own struct...

 struct Width { int width; alias width this; }

 foo(Width(10), Height(20));
Clearly this can be done better: struct _(string s) { int data; alias data this; } foo(_!"width"(10), _!"height"(20)); -- Simen
Feb 28 2011
parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 1, 11 05:04, Simen kjaeraas wrote:
 Adam Ruppe <destructionator gmail.com> wrote:

 Another alternative is to give each element their own struct...

 struct Width { int width; alias width this; }

 foo(Width(10), Height(20));
Clearly this can be done better: struct _(string s) { int data; alias data this; } foo(_!"width"(10), _!"height"(20));
How are these better than foo(/*width*/ 10, /*height*/ 20); ? One advantage of named parameter is the compiler can verify you've passed in the correct order, and all these alternatives cannot.
Feb 28 2011
parent Adam Ruppe <destructionator gmail.com> writes:
 ? One advantage of named parameter is the compiler can verify you've
 passed in the correct order, and all these alternatives cannot.
Separate structs would be checked because doing them out of order would be a type mistmatch.
Feb 28 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 02/28/2011 08:33 PM, Jonathan M Davis wrote:
 On Monday, February 28, 2011 11:02:37 Steven Schveighoffer wrote:
 On Mon, 28 Feb 2011 13:51:56 -0500, Jonathan M Davis<jmdavisProg gmx.com>

 wrote:
 I'm not entirely against named arguments being in D, however I do think
 that any
 functions that actually need them should be refactored anyway. So,
 ultimately,
 I'm not sure that they're really all that useful. I'm sure that they'd
 be useful
 upon occasion, but if you actually need them, then your function is
 taking too
 many arguments.

 In actuality, if I were to vote on whether named arguments should be in
 the
 language, I would definitely vote against it (I just plain don't want
 the code
 clutter, and they strike me as a crutch to avoid writing functions with
 good
 signatures in spite of their usefulness in some situations), but I can
 see why
 some people might want them.
Although I am not strongly for named arguments, I think they would be a definite improvement. Bearophile brought up one of the strongest cases for them: foo(int width, int height) {} Seems simple enough, I don't see how you have "too many arguments", but the call looks like this: foo(123, 456); So, looking at this call, can you tell which is width and which is height? I've seen some libs that use width and height do height first also. I usually have to go look up the API every time I'm reading/writing one of these. But this is perfectly clear and resists API changes/differences: foo(width: 123, height: 456); The cool part about this is, named arguments are not required -- you can always just not use them. But when you do use them, the code becomes much clearer.
That does have some minimal benefit, but if you're really passing around width and height much, then I'd argue that they should be put in a struct rather than passed around bare like that, and then that fixes the issue.
Precisely! Named arguments are a way to make an actual-parameter set a kind of named tuple, meaning a "free struct". Another place where it would be nice is return values: XYZ dimension (...) { ... return (width:123, height:456); } <OT> By the way, I wonder why people tend to systematically add one, and only one, space after ':', ',', ';' and never before. D code is not english! There is no reason to write "width: 123" rather than "width:123" or "width : 123". Rather the opposite, ':' expresses here a link which does not binds tightlier on left side than on right side ;-) Same about ';': it's a separator that has no reason to stick on left side, and not on right side! People are so conservative... </OT> Denis -- _________________ vita es estrany spir.wikidot.com
Feb 28 2011
parent bearophile <bearophileHUGS lycos.com> writes:
spir:

 <OT>
 By the way, I wonder why people tend to systematically add one, and only one, 
 space after ':', ',', ';' and never before. D code is not english!
You want to break English and Math rules only when you have a good reason. In Python PEP8 is quite specific:
    - Immediately before a comma, semicolon, or colon:

      Yes: if x == 4: print x, y; x, y = y, x
      No:  if x == 4 : print x , y ; x , y = y , x
 There is no reason to write "width: 123" rather than "width:123" or "width :
123".
"width :123" breaks an English rule for no purpose, and "width:123" is less readable, because there are less spaces that help the eye tell apart the parts of the text. "width : 123" looks more acceptable when you use it as a binding symbol. In functional languages sometimes you use ":" to tie list elements, and you use it with a space on both sides. Rather
 the opposite, ':' expresses here a link which does not binds tightlier on left 
 side than on right side ;-)
 Same about ';': it's a separator that has no reason to stick on left side, and 
 not on right side!
In D the ";" is used for purposes similar to English ones, as punctuation to denote when something (like a line) ends, so sticking it to the left is the right thing to do, because both English and most D is read from left to right. Bye, bearophile
Feb 28 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 I'm not entirely against named arguments being in D, however I do think that
any 
 functions that actually need them should be refactored anyway.
After your have refactored a function, I sometimes want to named arguments again. And sometimes you can't refactor an API, etc.
 (I just plain don't want the code clutter,
It's about as clutter as giving names to variables. And it's optional, you are not forced to call a function with named arguments in D (this sometimes happens in Python when the function accepts a **kwrg).
 and they strike me as a crutch to avoid writing functions with good 
 signatures in spite of their usefulness in some situations),
I'd like good signatures too. Bye, bearophile
Feb 28 2011
prev sibling parent Bekenn <leaveme alone.com> writes:
On 2/28/11 10:51 AM, Jonathan M Davis wrote:
 I'm not entirely against named arguments being in D, however I do think that
any
 functions that actually need them should be refactored anyway.
Are you the author of every function and method you call in your code?
Feb 28 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 02/28/2011 07:51 PM, Jonathan M Davis wrote:
 I'm not entirely against named arguments being in D, however I do think that
any
 functions that actually need them should be refactored anyway.
???
 In actuality, if I were to vote on whether named arguments should be in the
 language, I would definitely vote against it (I just plain don't want the code
 clutter,  [...]
Just don't use them! Denis -- _________________ vita es estrany spir.wikidot.com
Feb 28 2011
parent reply Don <nospam nospam.com> writes:
spir wrote:
 On 02/28/2011 07:51 PM, Jonathan M Davis wrote:
 I'm not entirely against named arguments being in D, however I do 
 think that any
 functions that actually need them should be refactored anyway.
I agree. CreateFont() in the Windows API, I'm looking at you. (For Linux people, that function has about 12 parameters).
 ???
 
 In actuality, if I were to vote on whether named arguments should be 
 in the
 language, I would definitely vote against it (I just plain don't want 
 the code
 clutter,  [...]
Just don't use them!
You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it). There are a couple of things that I really, really don't like about the names argument idea: 1. It makes parameter names part of the API. Providing no way for the function writer to control whether it is part of the API or not, and especially, doing it retrospectively, strikes me as extremely rude. 2. It introduces a different syntax for calling a function. foo(4, 5); foo(x: 4, y: 5); They look different, but they do exactly the same thing. I don't like that redundancy. Especially since, as far as I can tell, the named arguments are just comments (which the compiler can check). If so, a syntax like this would be possible, with no language change at all: pragma(namedarguments); // applies to whole module foo(/*x*/ 4, /*y*/ 5); ---> if a function parameter has a comment which forms a valid identifier, it's a named parameter. But I still don't see the need for this feature. Aren't people using IDEs where the function signature (with parameter names) pops up when you're entering the function, and when you move the mouse over the function call? And if you really want to see them all the time, why not build that feature into the IDE? ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
Feb 28 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, February 28, 2011 13:38:34 Don wrote:
 spir wrote:
 On 02/28/2011 07:51 PM, Jonathan M Davis wrote:
 I'm not entirely against named arguments being in D, however I do
 think that any
 functions that actually need them should be refactored anyway.
I agree. CreateFont() in the Windows API, I'm looking at you. (For Linux people, that function has about 12 parameters).
 ???
 
 In actuality, if I were to vote on whether named arguments should be
 in the
 language, I would definitely vote against it (I just plain don't want
 the code
 clutter,  [...]
Just don't use them!
You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it). There are a couple of things that I really, really don't like about the names argument idea: 1. It makes parameter names part of the API. Providing no way for the function writer to control whether it is part of the API or not, and especially, doing it retrospectively, strikes me as extremely rude. 2. It introduces a different syntax for calling a function. foo(4, 5); foo(x: 4, y: 5); They look different, but they do exactly the same thing. I don't like that redundancy. Especially since, as far as I can tell, the named arguments are just comments (which the compiler can check). If so, a syntax like this would be possible, with no language change at all: pragma(namedarguments); // applies to whole module foo(/*x*/ 4, /*y*/ 5); ---> if a function parameter has a comment which forms a valid identifier, it's a named parameter. But I still don't see the need for this feature. Aren't people using IDEs where the function signature (with parameter names) pops up when you're entering the function, and when you move the mouse over the function call? And if you really want to see them all the time, why not build that feature into the IDE? ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
I agree with pretty much everything said here. However, as I understand it, named parameters (at least as they work in Python) would allow for you to reorder parameters and give values for paramters which are normally default parameters without giving values for the default paramters before them, and those changes could not be dealt with by comments. However, I consider them to be a big _problem_, not a feature - _especially_ the ability to rearrange the function arguments. All of a sudden you could have foo(4, 5); foo(x : 4, y : 5); foo(y : 5, X : 4); all making _exactly_ the same function call. That seem _very_ bug-prone and confusing to me. foo(x : 4, y : 5) was bad enough, but allowing foo(y : 5, x : 4)? Not good. The amount of effort to understand the code becomes considerably higher. You could be very familiar with foo and know exactly what parameters it takes and totally mistake what it's really getting passed, because the arguments were flipped in comparison to the function parameters. I agree with Don. I think that named parameters would cause far more intellectual overhead and problems than they'd solve. - Jonathan M Davis - Jonathan M Davis
Feb 28 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 All of a sudden you could have
 
 foo(4, 5);
 foo(x : 4, y : 5);
 foo(y : 5, X : 4);
 
 all making _exactly_ the same function call. That seem _very_ bug-prone and 
 confusing to me.
(You have used an upper case X, this bug will be caught by the compiler). and often less buggy. If you swap all arguments in your program, using named arguments, you are probably making your program a little more bug-prone. So as most other features there's a way to misuse it. But in most cases you don't swap arguments, and you use names more semantically meaningful than just x and y, so swapped arguments sticks out more. And you also need to train yourself a bit, to see the arguments of function calls not in their of their order, but in term of their names, their semantics. If you use MatPlotLib (from Python) you learn to see the names of function arguments and mostly ignore the order you give them to functions (because the order is much less significant), so this feature needs a bit of training for the mind/attitude of the programmer too. Bye, bearophile
Feb 28 2011
prev sibling next sibling parent Bekenn <leaveme alone.com> writes:
On 2/28/11 1:50 PM, Jonathan M Davis wrote:
 However, I consider them to
 be a big _problem_, not a feature - _especially_ the ability to rearrange the
 function arguments. All of a sudden you could have

 foo(4, 5);
 foo(x : 4, y : 5);
 foo(y : 5, X : 4);

 all making _exactly_ the same function call. That seem _very_ bug-prone and
 confusing to me.
Of those three calls, the highest potential for confusion exists with the first. Admittedly, the third is of uncertain value.
Feb 28 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.2068.1298929852.4748.digitalmars-d puremagic.com...
 On Monday, February 28, 2011 13:38:34 Don wrote:
 There are a couple of things that I really, really don't like about the
 names argument idea:
 1. It makes parameter names part of the API.
 Providing no way for the function writer to control whether it is part
 of the API or not, and especially, doing it retrospectively, strikes me
 as extremely rude.

 2. It introduces a different syntax for calling a function.
 foo(4, 5);
 foo(x: 4, y: 5);
 They look different, but they do exactly the same thing. I don't like
 that redundancy.
a + b b + a a - (-b) b.opBinary!"+"(a); alias a poop; alias b butt; poop + butt (SomeType w, SomeType f) { return w - (-f); } (a, b) And yet, rightfully, no one gives half a shit that those redundancies are possible. (Oh my god, we shouldn't have unary minus, operator overloading, alias, or anonymous functions, because look at the possible redundancies they can create!!!)
 Especially since, as far as I can tell, the named arguments are just
 comments (which the compiler can check).
 If so, a syntax like this would be possible, with no language change at
 all:

 pragma(namedarguments); // applies to whole module

 foo(/*x*/ 4, /*y*/ 5);
Semantically-meaningful comments? Ultra-yuck! Plus that would seriously fuck up my habit of temporarily commenting out old arguments.
 ---> if a function parameter has a comment which forms a valid
 identifier, it's a named parameter.

 But I still don't see the need for this feature. Aren't people using
 IDEs where the function signature (with parameter names) pops up when
 you're entering the function, and when you move the mouse over the
 function call?
Wasn't your first objection "It makes parameter names part of the API"? Sounds like the same thing to me.
 However, I consider them to
 be a big _problem_, not a feature - _especially_ the ability to rearrange 
 the
 function arguments. All of a sudden you could have

 foo(4, 5);
 foo(x : 4, y : 5);
 foo(y : 5, X : 4);

 all making _exactly_ the same function call. That seem _very_ bug-prone 
 and
 confusing to me. foo(x : 4, y : 5) was bad enough, but allowing foo(y : 5, 
 x :
 4)? Not good. The amount of effort to understand the code becomes 
 considerably
 higher. You could be very familiar with foo and know exactly what 
 parameters it
 takes and totally mistake what it's really getting passed, because the 
 arguments
 were flipped in comparison to the function parameters.
1. I don't want to try to remember the "obvious" ordering of top, bottom, left and right. (Note that despite how I just happened to order them there, CSS considers it natural to go top, right, bottom, left instead. And I can't disagree that that's a perfectly intuitive ordering, too). 2. You've merely given an example of misuse. Everything can be misused. So that's a not a valid argument against it anyway.
Feb 28 2011
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Mon, 28 Feb 2011 13:50:52 -0800, Jonathan M Davis wrote:

 On Monday, February 28, 2011 13:38:34 Don wrote:
 spir wrote:
 On 02/28/2011 07:51 PM, Jonathan M Davis wrote:
 I'm not entirely against named arguments being in D, however I do
 think that any
 functions that actually need them should be refactored anyway.
I agree. CreateFont() in the Windows API, I'm looking at you. (For Linux people, that function has about 12 parameters).
 ???
 
 In actuality, if I were to vote on whether named arguments should be
 in the
 language, I would definitely vote against it (I just plain don't
 want the code
 clutter,  [...]
Just don't use them!
You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it). There are a couple of things that I really, really don't like about the names argument idea: 1. It makes parameter names part of the API. Providing no way for the function writer to control whether it is part of the API or not, and especially, doing it retrospectively, strikes me as extremely rude. 2. It introduces a different syntax for calling a function. foo(4, 5); foo(x: 4, y: 5); They look different, but they do exactly the same thing. I don't like that redundancy. Especially since, as far as I can tell, the named arguments are just comments (which the compiler can check). If so, a syntax like this would be possible, with no language change at all: pragma(namedarguments); // applies to whole module foo(/*x*/ 4, /*y*/ 5); ---> if a function parameter has a comment which forms a valid identifier, it's a named parameter. But I still don't see the need for this feature. Aren't people using IDEs where the function signature (with parameter names) pops up when you're entering the function, and when you move the mouse over the function call? And if you really want to see them all the time, why not build that feature into the IDE? ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
I agree with pretty much everything said here. However, as I understand it, named parameters (at least as they work in Python) would allow for you to reorder parameters and give values for paramters which are normally default parameters without giving values for the default paramters before them, and those changes could not be dealt with by comments. [...]
I think I agree with you and Don here. As for "skipping" default parameters, I suggest the following syntax: void foo(int i, bool b = true, real r = 3.14, string s = "") { ... } foo(1, , , "Hello World!"); This is a much smaller language change than named parameters. -Lars
Mar 01 2011
parent reply Bekenn <leaveme alone.com> writes:
On 3/1/11 1:51 AM, Lars T. Kyllingstad wrote:
 I think I agree with you and Don here.  As for "skipping" default
 parameters, I suggest the following syntax:

    void foo(int i, bool b = true, real r = 3.14, string s = "")
    { ... }

    foo(1, , , "Hello World!");

 This is a much smaller language change than named parameters.

 -Lars
When reading existing code, can you easily spot the difference between: foo(1,,, "Hello World!"); and foo(1,,,, "Hello World!"); ? Unlike named arguments, I'd argue this syntax makes things quite a bit /less/ readable.
Mar 01 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/1/11, Bekenn <leaveme alone.com> wrote:
 When reading existing code, can you easily spot the difference between:
 	foo(1,,, "Hello World!");
 and
 	foo(1,,,, "Hello World!");
 ?

 Unlike named arguments, I'd argue this syntax makes things quite a bit
 /less/ readable.
This syntax is used by Autohotkey, an automation scripting language. It's not that bad for scripting (when you have an api reference on the side). But when you're reading code you have to keep count of those commas, and that's when things get ugly.
Mar 01 2011
prev sibling parent reply Gareth Charnock <gareth.charnock gmail.com> writes:
Named arguments are useful when you have a function that takes a large 
number of parameters, the vast majority of which have default values. 
For example, have a look at this constructor in wxWidgets:



wxFrame::wxFrame	(	wxWindow * 	parent,
wxWindowID 	id,
const wxString & 	title,
const wxPoint & 	pos = wxDefaultPosition,
const wxSize & 	size = wxDefaultSize,
long 	style = wxDEFAULT_FRAME_STYLE,
const wxString & 	name = wxFrameNameStr	
)

If you want to change the name argument you need to call

new wxFrame(a_parent,wxANY,"Hello 
world",wxDefaultPosition,wxDefaultSize,wxDEFAULT_FRAME_STYLE,"My Custom 
name str")

Which meant I had to look up what the default values of pos,size and 
style where even though I was happy with those default values. The more 
arguments the more of a pain this setup is without named arguments. 
Contrast to a hypothetical C++ syntax:

new wxFrame(a_parent,wxANY,"Hello world",name = "My Custom name str")

I haven't bothered with the arguments I don't care about and my function 
call has ended up less sensitive to changes in the wxFrame constructor.

On 28/02/11 21:50, Jonathan M Davis wrote:
 On Monday, February 28, 2011 13:38:34 Don wrote:
 spir wrote:
 On 02/28/2011 07:51 PM, Jonathan M Davis wrote:
 I'm not entirely against named arguments being in D, however I do
 think that any
 functions that actually need them should be refactored anyway.
I agree. CreateFont() in the Windows API, I'm looking at you. (For Linux people, that function has about 12 parameters).
 ???

 In actuality, if I were to vote on whether named arguments should be
 in the
 language, I would definitely vote against it (I just plain don't want
 the code
 clutter,  [...]
Just don't use them!
You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it). There are a couple of things that I really, really don't like about the names argument idea: 1. It makes parameter names part of the API. Providing no way for the function writer to control whether it is part of the API or not, and especially, doing it retrospectively, strikes me as extremely rude. 2. It introduces a different syntax for calling a function. foo(4, 5); foo(x: 4, y: 5); They look different, but they do exactly the same thing. I don't like that redundancy. Especially since, as far as I can tell, the named arguments are just comments (which the compiler can check). If so, a syntax like this would be possible, with no language change at all: pragma(namedarguments); // applies to whole module foo(/*x*/ 4, /*y*/ 5); ---> if a function parameter has a comment which forms a valid identifier, it's a named parameter. But I still don't see the need for this feature. Aren't people using IDEs where the function signature (with parameter names) pops up when you're entering the function, and when you move the mouse over the function call? And if you really want to see them all the time, why not build that feature into the IDE? ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
I agree with pretty much everything said here. However, as I understand it, named parameters (at least as they work in Python) would allow for you to reorder parameters and give values for paramters which are normally default parameters without giving values for the default paramters before them, and those changes could not be dealt with by comments. However, I consider them to be a big _problem_, not a feature - _especially_ the ability to rearrange the function arguments. All of a sudden you could have foo(4, 5); foo(x : 4, y : 5); foo(y : 5, X : 4); all making _exactly_ the same function call. That seem _very_ bug-prone and confusing to me. foo(x : 4, y : 5) was bad enough, but allowing foo(y : 5, x : 4)? Not good. The amount of effort to understand the code becomes considerably higher. You could be very familiar with foo and know exactly what parameters it takes and totally mistake what it's really getting passed, because the arguments were flipped in comparison to the function parameters. I agree with Don. I think that named parameters would cause far more intellectual overhead and problems than they'd solve. - Jonathan M Davis - Jonathan M Davis
Mar 09 2011
next sibling parent Emil Madsen <sovende gmail.com> writes:
On 9 March 2011 13:22, Gareth Charnock <gareth.charnock gmail.com> wrote:

 Named arguments are useful when you have a function that takes a large
 number of parameters, the vast majority of which have default values. For
 example, have a look at this constructor in wxWidgets:




 wxFrame::wxFrame        (       wxWindow *      parent,
 wxWindowID      id,
 const wxString &        title,
 const wxPoint &         pos = wxDefaultPosition,
 const wxSize &  size = wxDefaultSize,
 long    style = wxDEFAULT_FRAME_STYLE,
 const wxString &        name = wxFrameNameStr
 )

 If you want to change the name argument you need to call

 new wxFrame(a_parent,wxANY,"Hello
 world",wxDefaultPosition,wxDefaultSize,wxDEFAULT_FRAME_STYLE,"My Custom name
 str")

 Which meant I had to look up what the default values of pos,size and style
 where even though I was happy with those default values. The more arguments
 the more of a pain this setup is without named arguments. Contrast to a
 hypothetical C++ syntax:

 new wxFrame(a_parent,wxANY,"Hello world",name = "My Custom name str")

 I haven't bothered with the arguments I don't care about and my function
 call has ended up less sensitive to changes in the wxFrame constructor.


 On 28/02/11 21:50, Jonathan M Davis wrote:

 On Monday, February 28, 2011 13:38:34 Don wrote:

 spir wrote:

 On 02/28/2011 07:51 PM, Jonathan M Davis wrote:

 I'm not entirely against named arguments being in D, however I do
 think that any
 functions that actually need them should be refactored anyway.
I agree. CreateFont() in the Windows API, I'm looking at you. (For Linux people, that function has about 12 parameters). ???
  In actuality, if I were to vote on whether named arguments should be
 in the
 language, I would definitely vote against it (I just plain don't want
 the code
 clutter,  [...]
Just don't use them!
You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it). There are a couple of things that I really, really don't like about the names argument idea: 1. It makes parameter names part of the API. Providing no way for the function writer to control whether it is part of the API or not, and especially, doing it retrospectively, strikes me as extremely rude. 2. It introduces a different syntax for calling a function. foo(4, 5); foo(x: 4, y: 5); They look different, but they do exactly the same thing. I don't like that redundancy. Especially since, as far as I can tell, the named arguments are just comments (which the compiler can check). If so, a syntax like this would be possible, with no language change at all: pragma(namedarguments); // applies to whole module foo(/*x*/ 4, /*y*/ 5); ---> if a function parameter has a comment which forms a valid identifier, it's a named parameter. But I still don't see the need for this feature. Aren't people using IDEs where the function signature (with parameter names) pops up when you're entering the function, and when you move the mouse over the function call? And if you really want to see them all the time, why not build that feature into the IDE? ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
I agree with pretty much everything said here. However, as I understand it, named parameters (at least as they work in Python) would allow for you to reorder parameters and give values for paramters which are normally default parameters without giving values for the default paramters before them, and those changes could not be dealt with by comments. However, I consider them to be a big _problem_, not a feature - _especially_ the ability to rearrange the function arguments. All of a sudden you could have foo(4, 5); foo(x : 4, y : 5); foo(y : 5, X : 4); all making _exactly_ the same function call. That seem _very_ bug-prone and confusing to me. foo(x : 4, y : 5) was bad enough, but allowing foo(y : 5, x : 4)? Not good. The amount of effort to understand the code becomes considerably higher. You could be very familiar with foo and know exactly what parameters it takes and totally mistake what it's really getting passed, because the arguments were flipped in comparison to the function parameters. I agree with Don. I think that named parameters would cause far more intellectual overhead and problems than they'd solve. - Jonathan M Davis - Jonathan M Davis
I actually like the idea of named variables, for these funktions that takes a lot of parameters, mostly because if the libary dev, chooses to change the default value of something, my old placeholder value, will end up being wrong without me knowing anything about it. Say: wxFrame::wxFrame ( wxWindow * parent, wxWindowID id, const wxString & title, const wxPoint & pos = wxDefaultPosition, const wxSize & size = wxDefaultSize, long style = wxDEFAULT_FRAME_STYLE, const wxString & name = wxFrameNameStr ) And I call it with the default args, because I have to, to change the name; however then the libary dev decides it would be better to have a default value of size = 800x600, now I'm not getting the default as I wanted to. -- // Yours sincerely // Emil 'Skeen' Madsen
Mar 09 2011
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 09/03/2011 12:22, Gareth Charnock wrote:
<snip>
 Which meant I had to look up what the default values of pos,size and style
where even
 though I was happy with those default values. The more arguments the more of a
pain this
 setup is without named arguments. Contrast to a hypothetical C++ syntax:

 new wxFrame(a_parent,wxANY,"Hello world",name = "My Custom name str")
<snip> This isn't hypothetical C++ syntax, it's perfectly legal C++ syntax. It is equivalent to name = "My Custom Name str", new wxFrame(a_parent, wxANY, "Hello world", name) Struct and array initialisers use a colon, not an equals sign, and if we add named arguments they would need to do the same to avoid changing the meaning of existing code. You may be just illustrating the concept and not proposing this as the actual syntax to add to C++ or D, but being careful now will help you to get used to the feature when/if it arrives. Stewart.
Mar 11 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:

You don't have that option. At least, if you're a library developer, you
don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it).< If you add named arguments to D, you are free to not use them when you call Phobos functions or functions from libraries not written by you. You have to see them only if you modify code written by other people that uses named arguments.
 There are a couple of things that I really, really don't like about the
 names argument idea:
 1. It makes parameter names part of the API.
 Providing no way for the function writer to control whether it is part
 of the API or not,
Probably I am don't understand something here. Function arguments need to be well chosen, so I don't mind them becoming part of the API. (In theory an annotation may be used to disallow the usage of named arguments for a specific function, but I think this is not necessary).
 and especially, doing it retrospectively, strikes me
 as extremely rude.
There is not much D2 code around, most D2 code is in the future, where this feature will hopefully be known to be present.
 2. It introduces a different syntax for calling a function.
 foo(4, 5);
 foo(x: 4, y: 5);
 They look different, but they do exactly the same thing. I don't like
 that redundancy.
In SPARK (Ada) they avoid that redundancy because you must use named arguments :-) To me they look the same, but the second also tells me what I am assigning numbers to.
 Especially since, as far as I can tell, the named arguments are just
 comments (which the compiler can check).
 If so, a syntax like this would be possible, with no language change at all:
 
 pragma(namedarguments); // applies to whole module
 
 foo(/*x*/ 4, /*y*/ 5);
 
 ---> if a function parameter has a comment which forms a valid
 identifier, it's a named parameter.
The two following are the same thing: foo(x: 4, y: 5); foo(y: 5, x: 4); While the following ones are not the same call: foo(/*x*/ 4, /*y*/ 5); foo(/*y*/ 5, /*x*/ 4); And if your function is: void foo(int x = 1, int y = 2) {} You are also able to write: foo(y: 5); That's not equivalent to: foo(/*y*/ 5); In Mathematica and Python there are plotting functions that have lot of parameters, all of them have a default argument. With named arguments you are able to choose to modify only one or few arguments, keeping your code readable and short and bug-free.
 But I still don't see the need for this feature. Aren't people using
 IDEs where the function signature (with parameter names) pops up when
 you're entering the function, and when you move the mouse over the
 function call?
If you print code on a book or you show code on the web, etc, you don't have an IDE to help you. Bye, bearophile
Feb 28 2011
next sibling parent Don <nospam nospam.com> writes:
bearophile wrote:
 Don:
 
 You don't have that option. At least, if you're a library developer, you
don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it).< If you add named arguments to D, you are free to not use them when you call Phobos functions or functions from libraries not written by you.
You have to see them only if you modify code written by other people that uses
named arguments.
This is complete rubbish. You cannot prevent someone from relying on your argument names. Changes to the language *always* affect everyone.
 There are a couple of things that I really, really don't like about the
 names argument idea:
 1. It makes parameter names part of the API.
 Providing no way for the function writer to control whether it is part
 of the API or not,
Probably I am don't understand something here. Function arguments need to be well chosen,
so I don't mind them becoming part of the API. Currently, they are documentation. Readable by a human. Making them part of the API is much more restrictive. Essentially, my chief objection to named arguments is that they severely limit your ability to improve the documentation after the function has been written. (In theory an annotation may be used to disallow the usage of named arguments for a specific function, but I think this is not necessary).
 
 
 and especially, doing it retrospectively, strikes me
 as extremely rude.
There is not much D2 code around, most D2 code is in the future, where this feature will hopefully be known to be present.
No, there's a huge body of existing code, most of it is in C.
 2. It introduces a different syntax for calling a function.
 foo(4, 5);
 foo(x: 4, y: 5);
 They look different, but they do exactly the same thing. I don't like
 that redundancy.
In SPARK (Ada) they avoid that redundancy because you must use named arguments :-) To me they look the same, but the second also tells me what I am assigning numbers to.
 Especially since, as far as I can tell, the named arguments are just
 comments (which the compiler can check).
 If so, a syntax like this would be possible, with no language change at all:

 pragma(namedarguments); // applies to whole module

 foo(/*x*/ 4, /*y*/ 5);

 ---> if a function parameter has a comment which forms a valid
 identifier, it's a named parameter.
The two following are the same thing: foo(x: 4, y: 5); foo(y: 5, x: 4);
Well, if you allowing changes in parameter ordering, it's a very much more complicated feature, that frankly I find very scary. It's of limited use but enormous complexity.
 But I still don't see the need for this feature. Aren't people using
 IDEs where the function signature (with parameter names) pops up when
 you're entering the function, and when you move the mouse over the
 function call?
If you print code on a book or you show code on the web, etc, you don't have an IDE to help you.
You can always put comments in.
 D isn't designed to require an IDE. 
Yes, but this seems like a personal preference.

 
 Bye,
 bearophile
Mar 01 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 28/02/2011 22:13, bearophile wrote:
 But I still don't see the need for this feature. Aren't people using
  IDEs where the function signature (with parameter names) pops up when
  you're entering the function, and when you move the mouse over the
  function call?
If you print code on a book or you show code on the web, etc, you don't have an IDE to help you. Bye, bearophile
This doesn't make it *required* to have an IDE. It perhaps just makes it better. The question that should be asked is if D should be optimized for IDE usage or not... -- Bruno Medeiros - Software Engineer
Mar 08 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Feb 2011 16:38:34 -0500, Don <nospam nospam.com> wrote:

 spir wrote:
  Just don't use them!
You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it).
encounter *reading* it or encounter *using it*? You shouldn't ever have to use named parameters if you don't want to. Just like you can specify all defaulted parameters, or specify all template args when calling templated functions. I could live without named parameters (obviously!), but I certainly think reading a call with named parameters can be much easier with the parameter names than without, and I don't think you could ever say the opposite (that name-less parameters would be clearer).
 There are a couple of things that I really, really don't like about the  
 names argument idea:
 1. It makes parameter names part of the API.
 Providing no way for the function writer to control whether it is part  
 of the API or not, and especially, doing it retrospectively, strikes me  
 as extremely rude.

 2. It introduces a different syntax for calling a function.
 foo(4, 5);
 foo(x: 4, y: 5);
 They look different, but they do exactly the same thing. I don't like  
 that redundancy.
I look at it similarly to IFTI: foo(T)(T t) {...} foo(1); foo!int(1); both mean the same, the int is optional. Note that the library developer of foo has no way to restrict you from using either form. One is simply a clearer way of saying the other. In essense, the parameter names are ALREADY an essential part of the API. If we didn't name the parameters (entirely possible with .di files!), how shitty would programming be?
 Especially since, as far as I can tell, the named arguments are just  
 comments (which the compiler can check).
 If so, a syntax like this would be possible, with no language change at  
 all:

 pragma(namedarguments); // applies to whole module

 foo(/*x*/ 4, /*y*/ 5);

 ---> if a function parameter has a comment which forms a valid  
 identifier, it's a named parameter.
There is a feature that isn't available via comments, parameter reordering: foo(y: 5, x: 4); Who in their right mind wants to do this, right? Well, consider you use two different libraries, and in one library the y is always the first parameter, and in another the x is always the first parameter (yes, I've seen shit like this). Calls to the separate libs might be a nightmare of continuous documentation referencing. But if you can just always say "x is first", then the calls are easy to read and write, and completely unambiguous.
 But I still don't see the need for this feature. Aren't people using  
 IDEs where the function signature (with parameter names) pops up when  
 you're entering the function, and when you move the mouse over the  
 function call?
Dunno, vim doesn't do that for me currently. Also, if reviewing code on github, there is no ide. -Steve
Feb 28 2011
next sibling parent reply Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:
 On Mon, 28 Feb 2011 16:38:34 -0500, Don <nospam nospam.com> wrote:
 
 spir wrote:
  Just don't use them!
You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it).
encounter *reading* it or encounter *using it*? You shouldn't ever have to use named parameters if you don't want to. Just like you can specify all defaulted parameters, or specify all template args when calling templated functions. I could live without named parameters (obviously!), but I certainly think reading a call with named parameters can be much easier with the parameter names than without, and I don't think you could ever say the opposite (that name-less parameters would be clearer).
For sure they can be clearer with nameless parameters! printf(formatstr: "Hello World!\n");
 In essense, the parameter names are ALREADY an essential part of the 
 API.  If we didn't name the parameters (entirely possible with .di 
 files!), how shitty would programming be?
The names are for humans to read. They are documentation. That's a big difference.
Mar 01 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Mar 2011 04:10:12 -0500, Don <nospam nospam.com> wrote:

 Steven Schveighoffer wrote:
 On Mon, 28 Feb 2011 16:38:34 -0500, Don <nospam nospam.com> wrote:

 spir wrote:
  Just don't use them!
You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it).
encounter *reading* it or encounter *using it*? You shouldn't ever have to use named parameters if you don't want to. Just like you can specify all defaulted parameters, or specify all template args when calling templated functions. I could live without named parameters (obviously!), but I certainly think reading a call with named parameters can be much easier with the parameter names than without, and I don't think you could ever say the opposite (that name-less parameters would be clearer).
For sure they can be clearer with nameless parameters! printf(formatstr: "Hello World!\n");
This is not less clear than printf("Hello World!\n"); It's as clear. More verbose, yes, but clear. Just like foo!int(1) is as clear as, but more verbose than, foo(1).
 In essense, the parameter names are ALREADY an essential part of the  
 API.  If we didn't name the parameters (entirely possible with .di  
 files!), how shitty would programming be?
The names are for humans to read. They are documentation. That's a big difference.
And they continue to be documentation, I'm documenting what my argument names are at the call site so I don't have to go back to the function definition to determine what each parameter is via position. Regarding your objection in another post, I see your point that you don't want to break existing code by changing a parameter name. A way to look at this is, you must choose good parameter names on the first try. Another way to look at it is, I'm documenting my function call -- I want to be notified by the compiler when the parameter names changed because I want to reassure myself that the call is still valid. My point is, the function author should choose good names, but if he must make a change, then fear of breaking calls should not dissuade him. We routinely change the names of functions or deprecate them, this is taken in stride by the users of the library, I don't see how changing parameter names is any different. -Steve
Mar 01 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 02/28/2011 11:13 PM, Steven Schveighoffer wrote:
 But I still don't see the need for this feature. Aren't people using IDEs
 where the function signature (with parameter names) pops up when you're
 entering the function, and when you move the mouse over the function call?
You are wrong Don, this is not an argument. The feature is *not* for writing code, but for reading it (first your own code). Obviously, if you can write parameter names, this means you know them somehow, lol! The names provide highly valuable info at /reading/ time.
 Dunno, vim doesn't do that for me currently.  Also, if reviewing code on
 github, there is no ide.
Geany does it, but only for currently open files. Meaning, to have it work when programming in D, I should have the whole stdlib open in geany tabs... Anyway, as said above, this feature is 'orthogonal' to the question discussed in this thread. I'm fed up with people opposing to features very relevant for code clarity, which they are not forced to use, and can hardly bother when reading code themselves. Is the second statement below really that hard to read? p = new Point([1,2,3], [3,2,1]); p = new Point(color:[1,2,3], pos:[3,2,1]); Denis -- _________________ vita es estrany spir.wikidot.com
Mar 01 2011
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 12:20:22 +0100, spir wrote:

 On 02/28/2011 11:13 PM, Steven Schveighoffer wrote:
 But I still don't see the need for this feature. Aren't people using
 IDEs where the function signature (with parameter names) pops up when
 you're entering the function, and when you move the mouse over the
 function call?
You are wrong Don, this is not an argument. The feature is *not* for writing code, but for reading it (first your own code). Obviously, if you can write parameter names, this means you know them somehow, lol! The names provide highly valuable info at /reading/ time.
 Dunno, vim doesn't do that for me currently.  Also, if reviewing code
 on github, there is no ide.
Geany does it, but only for currently open files. Meaning, to have it work when programming in D, I should have the whole stdlib open in geany tabs... Anyway, as said above, this feature is 'orthogonal' to the question discussed in this thread. I'm fed up with people opposing to features very relevant for code clarity, which they are not forced to use, and can hardly bother when reading code themselves. Is the second statement below really that hard to read? p = new Point([1,2,3], [3,2,1]); p = new Point(color:[1,2,3], pos:[3,2,1]);
Are the following really that hard to read? p = new Point(/* color */ [1,2,3], /* pos */ [3,2,1]); p = new Point( [1, 2, 3], // color [3, 2, 1], // pos ); -Lars
Mar 01 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 03/01/2011 12:48 PM, Lars T. Kyllingstad wrote:
 On Tue, 01 Mar 2011 12:20:22 +0100, spir wrote:

 On 02/28/2011 11:13 PM, Steven Schveighoffer wrote:
 But I still don't see the need for this feature. Aren't people using
 IDEs where the function signature (with parameter names) pops up when
 you're entering the function, and when you move the mouse over the
 function call?
You are wrong Don, this is not an argument. The feature is *not* for writing code, but for reading it (first your own code). Obviously, if you can write parameter names, this means you know them somehow, lol! The names provide highly valuable info at /reading/ time.
 Dunno, vim doesn't do that for me currently.  Also, if reviewing code
 on github, there is no ide.
Geany does it, but only for currently open files. Meaning, to have it work when programming in D, I should have the whole stdlib open in geany tabs... Anyway, as said above, this feature is 'orthogonal' to the question discussed in this thread. I'm fed up with people opposing to features very relevant for code clarity, which they are not forced to use, and can hardly bother when reading code themselves. Is the second statement below really that hard to read? p = new Point([1,2,3], [3,2,1]); p = new Point(color:[1,2,3], pos:[3,2,1]);
Are the following really that hard to read? p = new Point(/* color */ [1,2,3], /* pos */ [3,2,1]); p = new Point( [1, 2, 3], // color [3, 2, 1], // pos );
Just like the unittest feature is very simple and brings no new functionality (you can very easily write unittests w/o the feature), but having them an official feature makes it nicer, obvious, and used everywhere. Denis -- _________________ vita es estrany spir.wikidot.com
Mar 01 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:ikimed$2vba$5 digitalmars.com...
 On Tue, 01 Mar 2011 12:20:22 +0100, spir wrote:

 On 02/28/2011 11:13 PM, Steven Schveighoffer wrote:
 But I still don't see the need for this feature. Aren't people using
 IDEs where the function signature (with parameter names) pops up when
 you're entering the function, and when you move the mouse over the
 function call?
You are wrong Don, this is not an argument. The feature is *not* for writing code, but for reading it (first your own code). Obviously, if you can write parameter names, this means you know them somehow, lol! The names provide highly valuable info at /reading/ time.
 Dunno, vim doesn't do that for me currently.  Also, if reviewing code
 on github, there is no ide.
Geany does it, but only for currently open files. Meaning, to have it work when programming in D, I should have the whole stdlib open in geany tabs... Anyway, as said above, this feature is 'orthogonal' to the question discussed in this thread. I'm fed up with people opposing to features very relevant for code clarity, which they are not forced to use, and can hardly bother when reading code themselves. Is the second statement below really that hard to read? p = new Point([1,2,3], [3,2,1]); p = new Point(color:[1,2,3], pos:[3,2,1]);
Are the following really that hard to read? p = new Point(/* color */ [1,2,3], /* pos */ [3,2,1]); p = new Point( [1, 2, 3], // color [3, 2, 1], // pos ); -Lars
class Point { this(int[3] pos, int[3] color) {...} } p = new Point(/* color */ [1,2,3], /* pos */ [3,2,1]); Big Fail.
Mar 01 2011
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 01 Mar 2011 07:26:28 -0500, Nick Sabalausky wrote:

 "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message
 news:ikimed$2vba$5 digitalmars.com...
 On Tue, 01 Mar 2011 12:20:22 +0100, spir wrote:

 On 02/28/2011 11:13 PM, Steven Schveighoffer wrote:
 But I still don't see the need for this feature. Aren't people using
 IDEs where the function signature (with parameter names) pops up
 when you're entering the function, and when you move the mouse over
 the function call?
You are wrong Don, this is not an argument. The feature is *not* for writing code, but for reading it (first your own code). Obviously, if you can write parameter names, this means you know them somehow, lol! The names provide highly valuable info at /reading/ time.
 Dunno, vim doesn't do that for me currently.  Also, if reviewing code
 on github, there is no ide.
Geany does it, but only for currently open files. Meaning, to have it work when programming in D, I should have the whole stdlib open in geany tabs... Anyway, as said above, this feature is 'orthogonal' to the question discussed in this thread. I'm fed up with people opposing to features very relevant for code clarity, which they are not forced to use, and can hardly bother when reading code themselves. Is the second statement below really that hard to read? p = new Point([1,2,3], [3,2,1]); p = new Point(color:[1,2,3], pos:[3,2,1]);
Are the following really that hard to read? p = new Point(/* color */ [1,2,3], /* pos */ [3,2,1]); p = new Point( [1, 2, 3], // color [3, 2, 1], // pos ); -Lars
class Point { this(int[3] pos, int[3] color) {...} } p = new Point(/* color */ [1,2,3], /* pos */ [3,2,1]); Big Fail.
Yeah, I'm aware of that. I was merely opposing the "code clarity" argument by saying that we already have a feature for clarifying code: comments. Note that I'm not against named parameters per se, and I understand their benefits. I just think that, at this late point in D2's development, the cost of adding them outweighs the benefits. I mean, have you looked at the spec for D2 lately? It's starting to look like the OOXML spec! -Lars
Mar 01 2011
parent Bekenn <leaveme alone.com> writes:
On 3/1/11 4:40 AM, Lars T. Kyllingstad wrote:
 I just think that, at this late point in D2's development, the
 cost of adding them outweighs the benefits.  I mean, have you looked at
 the spec for D2 lately?  It's starting to look like the OOXML spec!
I started out a few weeks ago by reading through the entire spec as posted on the digitalmars site. It only took a few days of off-time reading. It's maybe a tenth the size of the C++ spec, if even that. Which is great -- I wouldn't want to needlessly bloat the spec -- but I don't think that argument carries much weight.
Mar 01 2011
prev sibling parent reply Max Samukha <spam spam.com> writes:
On 01.03.2011 13:20, spir wrote:
 I'm fed up with people opposing to features very relevant for code
 clarity, which they are not forced to use, and can hardly bother when
 reading code themselves. Is the second statement below really that hard
 to read?
      p = new Point([1,2,3], [3,2,1]);
      p = new Point(color:[1,2,3], pos:[3,2,1]);
I hate that "explicitness improves code clarity and readability" argument. It may be true in some cases but most of the time explicitness creates unnecessary redundancy that actually impairs readability. Add a couple more Point instances with explicitly specified argument names and you will have useless and annoying noise. Named arguments are definitely useful when one needs to avoid specifying default parameter values but I still think we can live a happy life without them. At least until D3.
Mar 01 2011
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 01.03.2011 15:52, Max Samukha wrote:
 On 01.03.2011 13:20, spir wrote:
 I'm fed up with people opposing to features very relevant for code
 clarity, which they are not forced to use, and can hardly bother when
 reading code themselves. Is the second statement below really that hard
 to read?
      p = new Point([1,2,3], [3,2,1]);
      p = new Point(color:[1,2,3], pos:[3,2,1]);
I hate that "explicitness improves code clarity and readability" argument. It may be true in some cases but most of the time explicitness creates unnecessary redundancy that actually impairs readability. Add a couple more Point instances with explicitly specified argument names and you will have useless and annoying noise. Named arguments are definitely useful when one needs to avoid specifying default parameter values but I still think we can live a happy life without them. At least until D3.
Seconded. -- Dmitry Olshansky
Mar 01 2011
prev sibling parent reply Bekenn <leaveme alone.com> writes:
On 3/1/11 4:52 AM, Max Samukha wrote:
 I hate that "explicitness improves code clarity and readability"
 argument. It may be true in some cases but most of the time explicitness
 creates unnecessary redundancy that actually impairs readability.
Correct. However, named arguments are not a "most of the time" feature. Just look at some Python code, where named arguments have been supported for a very long time; you'll still mostly see people making calls using positional arguments, which is as it should be. Named arguments are there for when they're helpful, and get out of the way when they're not.
Mar 01 2011
parent reply Max Samukha <spam spam.com> writes:
On 01.03.2011 20:55, Bekenn wrote:
 On 3/1/11 4:52 AM, Max Samukha wrote:
 I hate that "explicitness improves code clarity and readability"
 argument. It may be true in some cases but most of the time explicitness
 creates unnecessary redundancy that actually impairs readability.
Correct. However, named arguments are not a "most of the time" feature. Just look at some Python code, where named arguments have been supported for a very long time; you'll still mostly see people making calls using positional arguments, which is as it should be. Named arguments are there for when they're helpful, and get out of the way when they're not.
I am not against named arguments. What I wanted to say is that writef(formatstr: "...", ) does not make the code more readable. Also, I shudder at the thought that the compiler guys may stop working on the toolchain issues and rush to implement named arguments instead.
Mar 02 2011
parent Bekenn <leaveme alone.com> writes:
On 3/2/2011 1:34 AM, Max Samukha wrote:
 I am not against named arguments. What I wanted to say is that
 writef(formatstr: "...", ) does not make the code more readable.
Right, agreed. This is one of the "not helpful" cases, where you simply don't use named arguments. I'd expect (and hope for) most function calls to fall into that category.
 Also, I
 shudder at the thought that the compiler guys may stop working on the
 toolchain issues and rush to implement named arguments instead.
I'm only just becoming aware of the scope of the toolchain issues, so I'm not really qualified to comment on that. This doesn't have to go to the front of the queue, but it'd be nice to see it scheduled for D2.
Mar 02 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/28/11, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 Dunno, vim doesn't do that for me currently.

 -Steve
For C/C++, there's OmniCppComplete. It seems to do some parsing work and uses ctags. Now, I can use ctags and cscope in Vim with D, no problem there. But I haven't gotten around on getting autocompletion for D working. It might be possible to use the OmniCppComplete codebase and do a few edits here and there to make it work for D.
Mar 01 2011
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 28/02/2011 22:13, Steven Schveighoffer wrote:


 Dunno, vim doesn't do that for me currently.
I feel tempted to say something very short and concise regarding vim and emacs, but it would require a large amount of justification to properly expose such point. I am planning to write a blog post about that, but I haven't gotten to it yet.
 Also, if reviewing code on github, there is no ide.

 -Steve
A) Should we give any significant weight to very minute and relatively infrequent code reading situations, like web-based code reviewing in github or whatever, or reading code in books? I doubt so. B) If the pull request is large, it should be near effortless to put those changes in the IDE and review them there. -- Bruno Medeiros - Software Engineer
Mar 08 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Bruno Medeiros:

 A) Should we give any significant weight to very minute and relatively 
 infrequent code reading situations, like web-based code reviewing in 
 github or whatever, or reading code in books? I doubt so.
Named arguments allow to improve the reading of code everywhere, in editors too. Reading code in texts, emails, or online, is a common thing for me. I see every day pieces of code in this newsgroup. I suggest you to try to use for few months a language that allows named arguments.
The question that should be asked is if D should be optimized for IDE usage or
not...<
I think modern languages need to be designed to be aware of the existence of languages) have or have added named arguments even if they are often used in IDEs. Bye, bearophile
Mar 08 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 08 Mar 2011 15:29:28 -0500, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:

 On 28/02/2011 22:13, Steven Schveighoffer wrote:


 Dunno, vim doesn't do that for me currently.
I feel tempted to say something very short and concise regarding vim and emacs, but it would require a large amount of justification to properly expose such point. I am planning to write a blog post about that, but I haven't gotten to it yet. > Also, if reviewing code on github, there is no ide. > > -Steve A) Should we give any significant weight to very minute and relatively infrequent code reading situations, like web-based code reviewing in github or whatever, or reading code in books? I doubt so.
I contest that web based code reviewing is going to be infrequent, since all major phobos changes now must be reviewed by 2 peers before inclusion. Please look at a recent pull request review I participated in, without ever opening an editor/ide. GitHub provides very good collaborative review. If I have to install an IDE that I only use for reviewing, um... no. https://github.com/jmdavis/phobos/commit/aca1a2d7cfe7d5e934668e06028b78ffb6796245
 B) If the pull request is large, it should be near effortless to put  
 those changes in the IDE and review them there.
Again, don't have one. -Steve
Mar 08 2011
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 08/03/2011 21:37, Steven Schveighoffer wrote:
 On Tue, 08 Mar 2011 15:29:28 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 On 28/02/2011 22:13, Steven Schveighoffer wrote:


 Dunno, vim doesn't do that for me currently.
I feel tempted to say something very short and concise regarding vim and emacs, but it would require a large amount of justification to properly expose such point. I am planning to write a blog post about that, but I haven't gotten to it yet.
 Also, if reviewing code on github, there is no ide.

 -Steve
A) Should we give any significant weight to very minute and relatively infrequent code reading situations, like web-based code reviewing in github or whatever, or reading code in books? I doubt so.
I contest that web based code reviewing is going to be infrequent, since all major phobos changes now must be reviewed by 2 peers before inclusion. Please look at a recent pull request review I participated in, without ever opening an editor/ide. GitHub provides very good collaborative review. If I have to install an IDE that I only use for reviewing, um... no. https://github.com/jmdavis/phobos/commit/aca1a2d7cfe7d5e934668e06028b78ffb6796245
Hum, looking at that GitHub pull request (first time I have done so), GitHub does look quite nice in terms of code reviewing functionality. So, hum, I do agree that web-based code reviewing might become significantly frequent (if it is not already). (Note that I am not talking about Phobos development only) Although in the particular cased of named arguments, I still don't feel it is worthwhile. Not unless it could be done in a very orthogonal way (both in semantics and syntax), and even so it should likely be very low priority (as in, not any time soon...).
 B) If the pull request is large, it should be near effortless to put
 those changes in the IDE and review them there.
Again, don't have one. -Steve
Just because you don't have or don't use an IDE, that is not an argument against doing B). What should be considered is whether it is worthwhile to review it in an IDE or do it the web application, for a given change request. At the moment, probably not (although I would say it depends a lot on the D code and the underlying project). But in the future things might change. It could even be that a web-based application like GitHub would grow some IDE features, like the one about parameters context information. -- Bruno Medeiros - Software Engineer
Mar 09 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 09 Mar 2011 09:02:14 -0500, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:

 Although in the particular cased of named arguments, I still don't feel  
 it is worthwhile. Not unless it could be done in a very orthogonal way  
 (both in semantics and syntax), and even so it should likely be very low  
 priority (as in, not any time soon...).
It's one of those things where, in some cases, not having named arguments makes code unreadable. But having named arguments does not make *all* code more readable. In many many cases, code is readable just fine without using the named arguments. But those cases where it does help, it's essential. Like Don's CreateFont example (actually almost any GUI function). We might do something like require explicit comments for confusing functions like: foo( null, // paramA null, // paramB null, // paramC ); during the review process. It would at least document properly what is happening. I see not too much value in the "skip default parameter" prospect, most code can do fine without that via overloading. But the documentation and compiler verification of parameter names is what I see as the killer feature here.
 B) If the pull request is large, it should be near effortless to put
 those changes in the IDE and review them there.
Again, don't have one. -Steve
Just because you don't have or don't use an IDE, that is not an argument against doing B).
It absolutely is. I use NetBeans for doing php development. It took me hours and hours to set it up properly, install the right add-ons, etc. I'm not about to do that for something like descent or DDT so I can properly read code, I'm way more likely to just go look up the function signature myself for the few times I need it. Just having the named arguments idea makes so much more sense than having to load a specialized (and I might add, way overkill for just reviewing code in both size and complexity) tool. It's not one of those "absolutely have to have it" features, it's a nice-to-have. I certainly can and have lived without it, and there are certainly ways to compensate for not having it. It's kind of like arrays in D. Every time I have to use another language, I miss D's array syntax features. All the same functionality is there, it just takes more effort to do the same thing. That little effort is not terrible, but I much prefer not having to do it. -Steve
Mar 09 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 03/09/2011 06:20 PM, Steven Schveighoffer wrote:
 It's kind of like arrays in D.  Every time I have to use another language, I
 miss D's array syntax features.  All the same functionality is there, it just
 takes more effort to do the same thing.  That little effort is not terrible,
 but I much prefer not having to do it.
Agreed. This overall programmer-friendly design, is D's very big + for me. Denis -- _________________ vita es estrany spir.wikidot.com
Mar 09 2011
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 09/03/2011 17:20, Steven Schveighoffer wrote:
 On Wed, 09 Mar 2011 09:02:14 -0500, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 Although in the particular cased of named arguments, I still don't
 feel it is worthwhile. Not unless it could be done in a very
 orthogonal way (both in semantics and syntax), and even so it should
 likely be very low priority (as in, not any time soon...).
It's one of those things where, in some cases, not having named arguments makes code unreadable. But having named arguments does not make *all* code more readable. In many many cases, code is readable just fine without using the named arguments. But those cases where it does help, it's essential. Like Don's CreateFont example (actually almost any GUI function). We might do something like require explicit comments for confusing functions like: foo( null, // paramA null, // paramB null, // paramC ); during the review process. It would at least document properly what is happening. I see not too much value in the "skip default parameter" prospect, most code can do fine without that via overloading. But the documentation and compiler verification of parameter names is what I see as the killer feature here.
 B) If the pull request is large, it should be near effortless to put
 those changes in the IDE and review them there.
Again, don't have one. -Steve
Just because you don't have or don't use an IDE, that is not an argument against doing B).
It absolutely is. I use NetBeans for doing php development. It took me hours and hours to set it up properly, install the right add-ons, etc. I'm not about to do that for something like descent or DDT so I can properly read code, I'm way more likely to just go look up the function signature myself for the few times I need it. Just having the named arguments idea makes so much more sense than having to load a specialized (and I might add, way overkill for just reviewing code in both size and complexity) tool.
Now that is an argument. Although I still don't agree: it really shouldn't take that long to setup an IDE (if Netbeans and/or its PHP plugin are crappy, don't use that to blame all IDEs :P ). But in any case this is kinda besides the point, because setting up an IDE is a one-time affair (reviewing code is many-times). For small changes, yeah, it might be overkill to fire up an IDE. However I think the ideal solution in this issue is to bring a bit more IDE functionality to the web. There are already some projects loosely related to this underway, for example Orion (http://adtmag.com/articles/2011/03/21/eclipse-orion-hub.aspx ) from the Eclipse Foundation, of which Github is one of the involved parties. But for bigger changes (in fact even for smaller ones as well) it might be worthwhile to use an IDE tool, because it can offer a lot of help in navigation and other stuff related to reviewing the code. I mean, the named arguments only address a very limited problem in reviewing code: it only tells you which parameter corresponds each argument. But what if you need to read the function's documentation to know or remind yourself what the function does, if the arguments have correct values, respect the contract, etc.? You'll likely need to open the function declaration in any case, in one way or another. -- Bruno Medeiros - Software Engineer
Mar 23 2011
next sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 23/03/2011 16:12, Bruno Medeiros wrote:
 But for bigger changes (in fact even for smaller ones as well) it might
 be worthwhile to use an IDE tool, because it can offer a lot of help in
 navigation and other stuff related to reviewing the code. I mean, the
 named arguments only address a very limited problem in reviewing code:
 it only tells you which parameter corresponds each argument. But what if
 you need to read the function's documentation to know or remind yourself
 what the function does, if the arguments have correct values, respect
 the contract, etc.? You'll likely need to open the function declaration
 in any case, in one way or another.
Actually... what if you want to make sure it compiles? Or to run unit tests? Or just run and test it manually? You can't do any of those on the web. If you are just commenting on changes it might be fine, but if you are the one approving the code changes, I can hardly see how you can escape those tasks above (other than for very simple one-line changes), and thus the use of local tools. -- Bruno Medeiros - Software Engineer
Mar 23 2011
prev sibling parent reply Bekenn <leaveme alone.com> writes:
On 3/23/2011 9:12 AM, Bruno Medeiros wrote:
 Now that is an argument. Although I still don't agree: it really
 shouldn't take that long to setup an IDE (if Netbeans and/or its PHP
 plugin are crappy, don't use that to blame all IDEs :P ). But in any
 case this is kinda besides the point, because setting up an IDE is a
 one-time affair (reviewing code is many-times).
There is far more cost involved in using an IDE than the setup time. A typical IDE will: - Consume a relatively large chunk of space. Visual Studio on my system takes up 1.9 GB, with one of the platform SDKs taking up an additional 565 MB. XCode on my other system eats up a whopping 9.7 GB (!) with the iOS SDK (the download for XCode 4 with iOS SDK 4.3 is 4.2 GB for the .dmg file). Eclipse puts them both to shame at 268 MB for Eclipse Classic, with the JDK adding 179 MB on top of that. (I only use Eclipse for Android development, so I haven't installed anything beyond the base classic package.) For D development, I use Notepad++, which is just an editor -- 11.8 MB (plus 105 MB for dmd and associated tools). - Hijack file extensions. I have several versions of Visual Studio installed that all cooperate very nicely with each other, but if I were to install Eclipse for C/C++ development, I'd have to remember to tell it not to take over handling for .c/.cpp files. This isn't such a big deal if the IDE only handles one or two languages, but if it's a multi-language IDE, then there may be a list of twenty or more file types to scroll through, assuming that the installer is even nice enough to let you choose. - Have its own shortcuts, features, and quirks. In Visual Studio, I can hit tab to confirm intellisense suggestions. If I do the same thing in Eclipse, then I end up shifting focus over to the documentation popup window, which is just maddeningly stupid. XCode doesn't give me a list; it just inserts its suggestion inline, and then I have to either hit escape or keep typing if I want something else entirely. (XCode's suggestions also seem to be highly non-deterministic in nature; I think their algorithm would make for a great prng.) Build in Visual Studio is F7. In Eclipse, it's ctrl-b, which at least matches XCode's cmd-b. This can be mitigated in most cases by changing key bindings, but now you're looking at either a short list of commands that can be changed (which might not include the command you're looking for), or a very, *very* long list with hundreds of commands that you have to wade through. What's more, you have to figure out what name the IDE gives to the feature you're looking for, and it may not always be clear. Eclipse provides a search bar to make it easier; good thing, too, because typing "content assist" into that bar gives me back *21 different entries*! - Have its own unique, non-portable project format. Some IDEs can work with makefiles, but even most of those don't actually use a makefile as its preferred project format. This means that if you're looking at different projects from n different people/groups, you may need O(log(n)) different IDEs just to be able to open up their project. On the flip side, if you're the author of a project and you want people to be able to use their favorite IDE, then you have to provide several different sets of project configuration files. At least with makefiles, other people can build your project from the command-line without installing your favorite IDE. (Same goes for Visual Studio project files, actually; you can build those from the command line with MSBuild without having to install Visual Studio.) Lastly, at this point, D just doesn't have much in the line of support from major IDEs. There are neat projects like Descent and VisualD, but that's hardly the breadth or scope of support that you'd get with an established, highly-visible language. IDEs are simply not part of the language specification, and the language shouldn't be designed under the assumption that everyone's going to use an IDE, especially if you're thinking about a particular feature which many IDEs might not even have. Don't get me wrong -- I love IDEs. They can be very helpful, especially when it comes to dependency tracking and assisted editing. Right now, I use Notepad++ for D because I don't feel that the existing alternatives really offer that much useful functionality beyond what that editor provides. I'm working on some MSBuild tasks to make the process easier (yes, I develop primarily in Windows), and the IDE story will get better, but these things take a lot of time to fully materialize.
Mar 23 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 24.03.2011 07:36, schrieb Bekenn:
 On 3/23/2011 9:12 AM, Bruno Medeiros wrote:
 Now that is an argument. Although I still don't agree: it really
 shouldn't take that long to setup an IDE (if Netbeans and/or its PHP
 plugin are crappy, don't use that to blame all IDEs :P ). But in any
 case this is kinda besides the point, because setting up an IDE is a
 one-time affair (reviewing code is many-times).
There is far more cost involved in using an IDE than the setup time. A typical IDE will: - Consume a relatively large chunk of space. Visual Studio on my system takes up 1.9 GB, with one of the platform SDKs taking up an additional 565 MB. XCode on my other system eats up a whopping 9.7 GB (!) with the iOS SDK (the download for XCode 4 with iOS SDK 4.3 is 4.2 GB for the .dmg file). Eclipse puts them both to shame at 268 MB for Eclipse Classic, with the JDK adding 179 MB on top of that. (I only use Eclipse for Android development, so I haven't installed anything beyond the base classic package.) For D development, I use Notepad++, which is just an editor -- 11.8 MB (plus 105 MB for dmd and associated tools).
9,7GB is pretty much.. but how much of that is iOS SDK stuff? However: Eclipse is pretty bloated and still only uses <300MB in your configuration.. And in times of multiple Terabyte Harddisks a few hundred MBs (or even a 2-3GBs) for an IDE is not really a problem.
 - Hijack file extensions. I have several versions of Visual Studio
 installed that all cooperate very nicely with each other, but if I were
 to install Eclipse for C/C++ development, I'd have to remember to tell
 it not to take over handling for .c/.cpp files. This isn't such a big
 deal if the IDE only handles one or two languages, but if it's a
 multi-language IDE, then there may be a list of twenty or more file
 types to scroll through, assuming that the installer is even nice enough
 to let you choose.
This can happen with normal text editors as well and is more an issue of crappy IDEs that do this stuff without asking you than with IDEs in general.
 - Have its own shortcuts, features, and quirks. In Visual Studio, I can
 hit tab to confirm intellisense suggestions. If I do the same thing in
 Eclipse, then I end up shifting focus over to the documentation popup
 window, which is just maddeningly stupid. XCode doesn't give me a list;
 it just inserts its suggestion inline, and then I have to either hit
 escape or keep typing if I want something else entirely. (XCode's
 suggestions also seem to be highly non-deterministic in nature; I think
 their algorithm would make for a great prng.) Build in Visual Studio is
 F7. In Eclipse, it's ctrl-b, which at least matches XCode's cmd-b. This
 can be mitigated in most cases by changing key bindings, but now you're
 looking at either a short list of commands that can be changed (which
 might not include the command you're looking for), or a very, *very*
 long list with hundreds of commands that you have to wade through.
 What's more, you have to figure out what name the IDE gives to the
 feature you're looking for, and it may not always be clear. Eclipse
 provides a search bar to make it easier; good thing, too, because typing
 "content assist" into that bar gives me back *21 different entries*!
The same happens with normal editors, vi and emacs have totally different shortcuts. Cheers, - Daniel
Mar 24 2011
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 24/03/2011 06:36, Bekenn wrote:
 On 3/23/2011 9:12 AM, Bruno Medeiros wrote:
 Now that is an argument. Although I still don't agree: it really
 shouldn't take that long to setup an IDE (if Netbeans and/or its PHP
 plugin are crappy, don't use that to blame all IDEs :P ). But in any
 case this is kinda besides the point, because setting up an IDE is a
 one-time affair (reviewing code is many-times).
There is far more cost involved in using an IDE than the setup time. A typical IDE will: - Consume a relatively large chunk of space. Visual Studio on my system takes up 1.9 GB, with one of the platform SDKs taking up an additional 565 MB. XCode on my other system eats up a whopping 9.7 GB (!) with the iOS SDK (the download for XCode 4 with iOS SDK 4.3 is 4.2 GB for the .dmg file). Eclipse puts them both to shame at 268 MB for Eclipse Classic, with the JDK adding 179 MB on top of that. (I only use Eclipse for Android development, so I haven't installed anything beyond the base classic package.) For D development, I use Notepad++, which is just an editor -- 11.8 MB (plus 105 MB for dmd and associated tools). - Hijack file extensions. I have several versions of Visual Studio installed that all cooperate very nicely with each other, but if I were to install Eclipse for C/C++ development, I'd have to remember to tell it not to take over handling for .c/.cpp files. This isn't such a big deal if the IDE only handles one or two languages, but if it's a multi-language IDE, then there may be a list of twenty or more file types to scroll through, assuming that the installer is even nice enough to let you choose. - Have its own shortcuts, features, and quirks. In Visual Studio, I can hit tab to confirm intellisense suggestions. If I do the same thing in Eclipse, then I end up shifting focus over to the documentation popup window, which is just maddeningly stupid. XCode doesn't give me a list; it just inserts its suggestion inline, and then I have to either hit escape or keep typing if I want something else entirely. (XCode's suggestions also seem to be highly non-deterministic in nature; I think their algorithm would make for a great prng.) Build in Visual Studio is F7. In Eclipse, it's ctrl-b, which at least matches XCode's cmd-b. This can be mitigated in most cases by changing key bindings, but now you're looking at either a short list of commands that can be changed (which might not include the command you're looking for), or a very, *very* long list with hundreds of commands that you have to wade through. What's more, you have to figure out what name the IDE gives to the feature you're looking for, and it may not always be clear. Eclipse provides a search bar to make it easier; good thing, too, because typing "content assist" into that bar gives me back *21 different entries*! - Have its own unique, non-portable project format. Some IDEs can work with makefiles, but even most of those don't actually use a makefile as its preferred project format. This means that if you're looking at different projects from n different people/groups, you may need O(log(n)) different IDEs just to be able to open up their project. On the flip side, if you're the author of a project and you want people to be able to use their favorite IDE, then you have to provide several different sets of project configuration files. At least with makefiles, other people can build your project from the command-line without installing your favorite IDE. (Same goes for Visual Studio project files, actually; you can build those from the command line with MSBuild without having to install Visual Studio.) Lastly, at this point, D just doesn't have much in the line of support from major IDEs. There are neat projects like Descent and VisualD, but that's hardly the breadth or scope of support that you'd get with an established, highly-visible language. IDEs are simply not part of the language specification, and the language shouldn't be designed under the assumption that everyone's going to use an IDE, especially if you're thinking about a particular feature which many IDEs might not even have. Don't get me wrong -- I love IDEs. They can be very helpful, especially when it comes to dependency tracking and assisted editing. Right now, I use Notepad++ for D because I don't feel that the existing alternatives really offer that much useful functionality beyond what that editor provides. I'm working on some MSBuild tasks to make the process easier (yes, I develop primarily in Windows), and the IDE story will get better, but these things take a lot of time to fully materialize.
Well, now we go back to discussion of the discussion of whether one thinks it's worthwhile to use and IDE or not (for general development, not just code reviews). I don't want to go into this discussion again, at least not now so soon. I think that what we all may take from the discussion I was having from Steven right now, and maybe everyone agree with, is that whether it's worthwhile to use an IDE for code reviews is reduced to the discussion of whether it's worthwhile to use an IDE generally or not. In other words, if you don't do the tasks I mentioned before (looking up documentation, compiling and running code, running tests. also, using the source control system) from inside the IDE when developing yourself, you will definitely won't want to use it when code reviewing, accepting patches, etc.. -- Bruno Medeiros - Software Engineer
Mar 24 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 24 Mar 2011 10:33:28 -0400, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:

 Well, now we go back to discussion of the discussion of whether one  
 thinks it's worthwhile to use and IDE or not (for general development,  
 not just code reviews).
 I don't want to go into this discussion again, at least not now so soon.  
 I think that what we all may take from the discussion I was having from  
 Steven right now, and maybe everyone agree with, is that whether it's  
 worthwhile to use an IDE for code reviews is reduced to the discussion  
 of whether it's worthwhile to use an IDE generally or not. In other  
 words, if you don't do the tasks I mentioned before (looking up  
 documentation, compiling and running code, running tests. also, using  
 the source control system) from inside the IDE when developing yourself,  
 you will definitely won't want to use it when code reviewing, accepting  
 patches, etc..
Building on that, I'll actually put it another way: Without netbeans, I would be twice as slow with php development. Being a non-static language, with so many little quirks and annoyances that come with, I find netbeans' features essential (my most favorite is the recent ability to "type" object variables so you can look at the documented members). In fact, I'd be way more likely to install a D for netbeans plugin than I would to install another IDE specifically for D. But with D, I find the online documentation and included tools "good enough" for most development. I'm also way more familiar with D's library than I am with php's. I don't know if it's a good apples-to-apples comparison, but I simply feel no need to have an IDE to read D code. I don't feel the same way about php :) Having named arguments would add to that feeling of comfort, I believe. -Steve P.S. I've tried two D ides in the past for about 10 minutes (descent and code::blocks), could not get either of them to work right. And it was *not* trivial to set them up.
Mar 24 2011
next sibling parent reply Andrew Wiley <debio264 gmail.com> writes:
On Thu, Mar 24, 2011 at 3:23 PM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 On Thu, 24 Mar 2011 10:33:28 -0400, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 Well, now we go back to discussion of the discussion of whether one thin=
ks
 it's worthwhile to use and IDE or not (for general development, not just
 code reviews).
 I don't want to go into this discussion again, at least not now so soon.=
I
 think that what we all may take from the discussion I was having from St=
even
 right now, and maybe everyone agree with, is that whether it's worthwhil=
e to
 use an IDE for code reviews is reduced to the discussion of whether it's
 worthwhile to use an IDE generally or not. In other words, if you don't =
do
 the tasks I mentioned before (looking up documentation, compiling and
 running code, running tests. also, using the source control system) from
 inside the IDE when developing yourself, you will definitely won't want =
to
 use it when code reviewing, accepting patches, etc..
Building on that, I'll actually put it another way: Without netbeans, I would be twice as slow with php development. =A0Being=
a
 non-static language, with so many little quirks and annoyances that come
 with, I find netbeans' features essential (my most favorite is the recent
 ability to "type" object variables so you can look at the documented
 members). =A0In fact, I'd be way more likely to install a D for netbeans
 plugin than I would to install another IDE specifically for D.

 But with D, I find the online documentation and included tools "good enou=
gh"
 for most development. =A0I'm also way more familiar with D's library than=
I am
 with php's.

 I don't know if it's a good apples-to-apples comparison, but I simply fee=
l
 no need to have an IDE to read D code. =A0I don't feel the same way about=
php
 :) =A0Having named arguments would add to that feeling of comfort, I beli=
eve.
 -Steve

 P.S. I've tried two D ides in the past for about 10 minutes (descent and
 code::blocks), could not get either of them to work right. =A0And it was =
*not*
 trivial to set them up.
I would make the argument that once you started working with a D IDE with enough features, you'd probably find yourself addicted to it as you are with PHP and Netbeans. At least, that's been my experience across just about every language I've coded in.
Mar 24 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 24 Mar 2011 23:39:30 -0400, Andrew Wiley <debio264 gmail.com>  
wrote:

 I would make the argument that once you started working with a D IDE
 with enough features, you'd probably find yourself addicted to it as
 you are with PHP and Netbeans. At least, that's been my experience
 across just about every language I've coded in.
/me likes my vi :) I know ides can mimic vi, or use vi directly to edit, but for most purposes, vi + online docs suits my style well. I don't dislike IDEs per se, I've used Visual Studio quite a bit and I like it, though it's not supported on my current OS (Linux). I also think NetBeans is pretty good, it certainly makes php coding more enjoyable. But I will never, ever install an IDE for the sole purpose of reviewing code. And I don't see the problem with making code more understandable without an IDE. The point that named parameters a "useless" feature because IDEs already take care of that is what I disagree with, not that IDEs are useful. -Steve
Mar 25 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 24/03/2011 20:23, Steven Schveighoffer wrote:
 P.S. I've tried two D ides in the past for about 10 minutes (descent and
 code::blocks), could not get either of them to work right. And it was
 *not* trivial to set them up.
I must invite you try out DDT :D , even you don't stick to using it aferward. It should be no more than 5 minutes to setup (download times excluding): http://code.google.com/a/eclipselabs.org/p/ddt/wiki/UserGuide *fingers crossed* -- Bruno Medeiros - Software Engineer
Mar 29 2011
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 3/8/2011 12:29 PM, Bruno Medeiros wrote:
 On 28/02/2011 22:13, Steven Schveighoffer wrote:
 
 
 Dunno, vim doesn't do that for me currently.
I feel tempted to say something very short and concise regarding vim and emacs, but it would require a large amount of justification to properly expose such point. I am planning to write a blog post about that, but I haven't gotten to it yet.
 Also, if reviewing code on github, there is no ide.

 -Steve
A) Should we give any significant weight to very minute and relatively infrequent code reading situations, like web-based code reviewing in github or whatever, or reading code in books? I doubt so. B) If the pull request is large, it should be near effortless to put those changes in the IDE and review them there.
Personally, I spend _way_ more time reading code (mine or other peoples) than I spend writing code. Ignoring time, I also read far more lines/files/whatever code than I write. I suspect these things are going to vary highly from person to person and from job role to job role. Those that primarily produce new applications, tools, websites, etc and do little maintenance programming will be the polar opposite. Regarding B, if a pull/review request is large, I'll likely send it back with instructions to break it into small pull requests. Or at a minimum a series of small commits. Gigantic lumps of code (particularly many separable changes all done at once) are just a bad idea no matter how you arrange it. My 2 cents, Brad
Mar 08 2011
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 09/03/2011 06:10, Brad Roberts wrote:
 Personally, I spend_way_  more time reading code (mine or other peoples) than
I spend writing code.  Ignoring time, I
 also read far more lines/files/whatever code than I write.  I suspect these
things are going to vary highly from person
 to person and from job role to job role.  Those that primarily produce new
applications, tools, websites, etc and do
 little maintenance programming will be the polar opposite.
Me too, I also spend a lot of time reading and trying to understand code, especially when working with Eclipse, which is a huge code base. But I do it inside the IDE. I didn't mean reading in any kind of situation, but only minute ones when tools are not available. Like reading a book, reading a online guide/tutorial/snippet, etc.. -- Bruno Medeiros - Software Engineer
Mar 09 2011
prev sibling next sibling parent reply Bekenn <leaveme alone.com> writes:
On 2/28/11 1:38 PM, Don wrote:
 spir wrote:
 On 02/28/2011 07:51 PM, Jonathan M Davis wrote:
 I'm not entirely against named arguments being in D, however I do
 think that any
 functions that actually need them should be refactored anyway.
I agree. CreateFont() in the Windows API, I'm looking at you. (For Linux people, that function has about 12 parameters).
That's a great example of where named parameters can come in very handy. As a consumer of the API, you do not have the option of refactoring CreateFont(); you have to play the cards you're dealt. Named arguments allow you to annotate in a compiler-verified fashion.
 Just don't use them!
You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it).
You may encounter it, but nothing says you ever have to write it. There is no way to write a function such that callers would have to use named arguments in the function call. (If there were, then I'd agree with you -- that would be bad.)
 There are a couple of things that I really, really don't like about the
 names argument idea:
 1. It makes parameter names part of the API.
 Providing no way for the function writer to control whether it is part
 of the API or not, and especially, doing it retrospectively, strikes me
 as extremely rude.
A valid point. I think I would already consider parameter names to be part of the API, though; generated documentation relies upon them, as do contracts. Admittedly, this would be the first place where they leak directly into caller code.
 2. It introduces a different syntax for calling a function.
 foo(4, 5);
 foo(x: 4, y: 5);
 They look different, but they do exactly the same thing. I don't like
 that redundancy.
You're right, it is redundant. So is this: Declaration: void func(int a = 0); Use: func(); // ok func(0); // same as above Are you also against default arguments, then?
 Especially since, as far as I can tell, the named arguments are just
 comments (which the compiler can check).
Look again at my example from the first post: HRESULT hr = m_Device.Present(hDestWindowOverride: hOverride); In this usage, the named argument allows me to skip over the first two parameters, which receive their default arguments. This seems highly valuable to me.
 But I still don't see the need for this feature. Aren't people using
 IDEs where the function signature (with parameter names) pops up when
 you're entering the function, and when you move the mouse over the
 function call?
The point (in the annotation use case) is less in the writing than in the reading.
Feb 28 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, February 28, 2011 14:25:05 Bekenn wrote:
 On 2/28/11 1:38 PM, Don wrote:
 spir wrote:
 On 02/28/2011 07:51 PM, Jonathan M Davis wrote:
 I'm not entirely against named arguments being in D, however I do
 think that any
 functions that actually need them should be refactored anyway.
I agree. CreateFont() in the Windows API, I'm looking at you. (For Linux people, that function has about 12 parameters).
That's a great example of where named parameters can come in very handy. As a consumer of the API, you do not have the option of refactoring CreateFont(); you have to play the cards you're dealt. Named arguments allow you to annotate in a compiler-verified fashion.
 Just don't use them!
You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it).
You may encounter it, but nothing says you ever have to write it. There is no way to write a function such that callers would have to use named arguments in the function call. (If there were, then I'd agree with you -- that would be bad.)
 There are a couple of things that I really, really don't like about the
 names argument idea:
 1. It makes parameter names part of the API.
 Providing no way for the function writer to control whether it is part
 of the API or not, and especially, doing it retrospectively, strikes me
 as extremely rude.
A valid point. I think I would already consider parameter names to be part of the API, though; generated documentation relies upon them, as do contracts. Admittedly, this would be the first place where they leak directly into caller code.
And that's a _big_ problem. For instance, how many parameter names in Phobos were chosen with the idea that a caller would use them? _None_. And now, if named arguments are added, all of a sudden, you can't rename parameters without breaking code. I, for one, do not want to _increase_ the number of things that I can't change in code without breaking other people's code. And at least with functions, I could rename them and leave a deprecated alias. With parameters, I don't have that option. A poorly named parameter would be set in stone unless the whole function were renamed or we were willing to break other people's code. Named arguments _decrease_ flexibility as far as the API goes. On top of that, we would then have to worry about having high consistency in parameter names instead of just in function names. From the perspective of the library writer, this causes _more_ problems at _no_ benefit. From the perspective of the library user, it does provide some benefit, but I honestly do not think that func(x : 4, y : 5); is easier to read than func(4, 5); Sure, you have to know what func's parameters are, but you have to know that anyway. Only now, with named arguments, you have to care about what their _names_ are in addition to what they're for. I do _not_ want to have to read code which uses named arguments. It's just more clutter and more intellectual overhead. The sole type of case that I have seen where named arguments are of real benefit is where you're dealing with horribly written functions that have a ton of parameters, and I would _hope_ that that kind of nonsense would be restricted to old C APIs and the like. And if you have to deal with such C APIs from D, you can write a wrapper which uses a proper struct or whatnot to encapsulate that mess. Such horrendous functions shouldn't be the norm at all. As a library user, I see little benefit to named arguments and a definite problem with them in terms the added code clutter and intellectual overhead. As a library writer, it gives me _no_ benefit and definitely makes my life harder. Parameter names have never been part of a function's signature, and I _don't_ want them to start being a part of it now. The more I think about this, the more I'm against the idea of named arguments. - Jonathan M Davis
Feb 28 2011
next sibling parent Jim <bitcirkel yahoo.com> writes:
Jonathan M Davis Wrote:

 On Monday, February 28, 2011 14:25:05 Bekenn wrote:
 On 2/28/11 1:38 PM, Don wrote:
 spir wrote:
 On 02/28/2011 07:51 PM, Jonathan M Davis wrote:
 I'm not entirely against named arguments being in D, however I do
 think that any
 functions that actually need them should be refactored anyway.
I agree. CreateFont() in the Windows API, I'm looking at you. (For Linux people, that function has about 12 parameters).
That's a great example of where named parameters can come in very handy. As a consumer of the API, you do not have the option of refactoring CreateFont(); you have to play the cards you're dealt. Named arguments allow you to annotate in a compiler-verified fashion.
 Just don't use them!
You don't have that option. At least, if you're a library developer, you don't. (I'm a bit sick of people saying "you don't have to use it if you don't want to" in language design. If it is in the language, you don't have a choice. You will encounter it).
You may encounter it, but nothing says you ever have to write it. There is no way to write a function such that callers would have to use named arguments in the function call. (If there were, then I'd agree with you -- that would be bad.)
 There are a couple of things that I really, really don't like about the
 names argument idea:
 1. It makes parameter names part of the API.
 Providing no way for the function writer to control whether it is part
 of the API or not, and especially, doing it retrospectively, strikes me
 as extremely rude.
A valid point. I think I would already consider parameter names to be part of the API, though; generated documentation relies upon them, as do contracts. Admittedly, this would be the first place where they leak directly into caller code.
And that's a _big_ problem. For instance, how many parameter names in Phobos were chosen with the idea that a caller would use them? _None_. And now, if named arguments are added, all of a sudden, you can't rename parameters without breaking code. I, for one, do not want to _increase_ the number of things that I can't change in code without breaking other people's code. And at least with functions, I could rename them and leave a deprecated alias. With parameters, I don't have that option. A poorly named parameter would be set in stone unless the whole function were renamed or we were willing to break other people's code. Named arguments _decrease_ flexibility as far as the API goes. On top of that, we would then have to worry about having high consistency in parameter names instead of just in function names. From the perspective of the library writer, this causes _more_ problems at _no_ benefit. From the perspective of the library user, it does provide some benefit, but I honestly do not think that func(x : 4, y : 5); is easier to read than func(4, 5); Sure, you have to know what func's parameters are, but you have to know that anyway. Only now, with named arguments, you have to care about what their _names_ are in addition to what they're for. I do _not_ want to have to read code which uses named arguments. It's just more clutter and more intellectual overhead. The sole type of case that I have seen where named arguments are of real benefit is where you're dealing with horribly written functions that have a ton of parameters, and I would _hope_ that that kind of nonsense would be restricted to old C APIs and the like. And if you have to deal with such C APIs from D, you can write a wrapper which uses a proper struct or whatnot to encapsulate that mess. Such horrendous functions shouldn't be the norm at all. As a library user, I see little benefit to named arguments and a definite problem with them in terms the added code clutter and intellectual overhead. As a library writer, it gives me _no_ benefit and definitely makes my life harder. Parameter names have never been part of a function's signature, and I _don't_ want them to start being a part of it now. The more I think about this, the more I'm against the idea of named arguments. - Jonathan M Davis
I think it could be a real boon for generic code: class House(Roof = Clay, Door = Wood, Window = Glass) { Roof _roof; Door[] _doors; Window[] _windows; } auto home = new House(Roof: Gingerbread, Window: Sugar)(); You would probably parameterize as much as possible, like the container types for _doors and _windows -- i.e. anything that isn't limited by the algorithm of your choice. Everything being optional of course, and all the work is all done at compile time. This would give you _rich_ generic types with plain interfaces. You only specify what's important to you. How's that for a template library where every part can be shifted and replaced?
Feb 28 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/28/11 6:03 PM, Jonathan M Davis wrote:
 The more I think about this, the more I'm against the idea of named arguments.
I think you have been blessed to work with only small, clean APIs. Certain domains definitely promote large argument lists. Though the designs could certainly be refactored to e.g. group parameters into separate objects, it's overkill to do that. I'm afraid sheer experience is showing that your counterarguments are not based. Andrei
Feb 28 2011
next sibling parent dsimcha <dsimcha yahoo.com> writes:
On 2/28/2011 8:48 PM, Andrei Alexandrescu wrote:
 On 2/28/11 6:03 PM, Jonathan M Davis wrote:
 The more I think about this, the more I'm against the idea of named
 arguments.
I think you have been blessed to work with only small, clean APIs. Certain domains definitely promote large argument lists. Though the designs could certainly be refactored to e.g. group parameters into separate objects, it's overkill to do that. I'm afraid sheer experience is showing that your counterarguments are not based. Andrei
Agreed. I don't know how many times, when designing an API, I've considered making something configurable and instead just hard coded it to avoid bloating things with yet another regular (must be passed in-order) function argument or (if I put the options in a struct) yet another type. Besides, using structs to hold options requires boilerplate for the user of the library. What would you rather write? A: Options options; options.someOption = someValue; fun(mandatoryArg1, mandatoryArg2, options); B: fun(mandatoryArg1, mandatoryArg2, someOption = someValue); The beauty of named arguments with defaults is that they allow you to make things configurable with as little boilerplate code as possible for the library writer and as little boilerplate as possible for the user in the case where such configurability isn't needed.
Feb 28 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 03/01/2011 02:48 AM, Andrei Alexandrescu wrote:
 On 2/28/11 6:03 PM, Jonathan M Davis wrote:
 The more I think about this, the more I'm against the idea of named arguments.
I think you have been blessed to work with only small, clean APIs. Certain domains definitely promote large argument lists. Though the designs could certainly be refactored to e.g. group parameters into separate objects, it's overkill to do that. I'm afraid sheer experience is showing that your counterarguments are not based.
It seems to me the core point is whether what params mean, and their order, is obvious. Rather than their sheer number. Reading code using names for params is a huge help in understanding it, and also in learning the APIs. Meaning what one can do, why it is useful, and how to proceed concretely. I would be for all tutorial-like code (esp in "official" ref doc), examples, and even unittests more or less intended as code samples, to use named params everywhere. Denis -- _________________ vita es estrany spir.wikidot.com
Mar 01 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.2069.1298937813.4748.digitalmars-d puremagic.com...
 And that's a _big_ problem. For instance, how many parameter names in 
 Phobos
 were chosen with the idea that a caller would use them? _None_.
If Phobos parameter names are that bad, then Phobos has both a code-quality problem and a documentation-quality problem.
 And now, if
 named arguments are added, all of a sudden, you can't rename parameters 
 without
 breaking code.

 I, for one, do not want to _increase_ the number of things that I
 can't change in code without breaking other people's code.  And at least 
 with
 functions, I could rename them and leave a deprecated alias. With 
 parameters, I
 don't have that option. A poorly named parameter would be set in stone 
 unless
 the whole function were renamed or we were willing to break other people's 
 code.
 Named arguments _decrease_ flexibility as far as the API goes.
I don't understand why people have such a problem with changed names in an API. Updating calls to use a new name is fucking trivial. How many seconds of terrible, miserable, back-breaking work did you have to suffer through to update your code for the new name changes in DMD 2.052? Granted it would be a problem if they were constantly changing everything's name around, but nobody does that even for private symbols. And if you really want to be obsessive-compulsive about it, there's always this: void foo(int a) { alias a b; ... }
 On top of that, we would then have to worry about having high consistency 
 in
 parameter names instead of just in function names. From the perspective of 
 the
 library writer, this causes _more_ problems at _no_ benefit.
The "problem" is downright trivial, and as a library writer I'd certainly consider providing my users with a less error-prone API to be of benefit to me.
 From the perspective
 of the library user, it does provide some benefit, but I honestly do not 
 think
 that

 func(x : 4, y : 5);

 is easier to read than

 func(4, 5);

 Sure, you have to know what func's parameters are, but you have to know 
 that
 anyway.
But you no longer have to give a shit what their arbitrarily chosen order is. X and Y may have an obvious natural ordering, but a lot of things don't.
 Only now, with named arguments, you have to care about what their
 _names_ are in addition to what they're for. I do _not_ want to have to 
 read
 code which uses named arguments. It's just more clutter and more 
 intellectual
 overhead.
I do _not_ want to have to read code like this: box(10, 15, 5, 12) Quiz: Could you tell which of the following that is without referring to any docs?: - box(top, bottom, left, right) - box(top, right, bottom, left) - box(x, y, width, height) - box(x, y, rgb color, alpha) - box(x, y, z, hsl color) - Or maybe the API author was stupid and made it something like box(height, x, width, y) One could argue the code is more likely like this: int x = 1; int y = 2; int width = 3; int height = 4; ... box(x, y, width, height) But if you look at that, do you actually *know* the API is "x, y, width, height"? Nope. Could be a bug staring you right in the face. Other people have addressed the "IDE API pop-up" issue. Additionally, I do _not_ want to have to read code like this: Rect rect; rect.top = 1; rect.bottom = 2; rect.left = 3; rect.right = 4; box(rect) (And yes, there's "with", but IMO that makes it even worse.) And note that that's only 4 params, not remotely "a ton". MS has a lot of APIs like that and even for small structs (*especially* for small structs) it quickly makes the user code a mess.
Feb 28 2011
parent Bekenn <leaveme alone.com> writes:
On 2/28/11 9:07 PM, Nick Sabalausky wrote:
 One could argue the code is more likely like this:

      int x = 1;
      int y = 2;
      int width = 3;
      int height = 4;
      ...
      box(x, y, width, height)
Right, at which point you're essentially using named arguments anyway, except that here, a) it's not verified by the compiler, b) you've added stack or static variables (perhaps needlessly), and c) you're polluting the local namespace.
Mar 01 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 03/01/2011 01:03 AM, Jonathan M Davis wrote:
  From the perspective
 of the library user, it does provide some benefit, but I honestly do not think
 that

 func(x : 4, y : 5);

 is easier to read than

 func(4, 5);

 Sure, you have to know what func's parameters are, but you have to know that
 anyway. Only now, with named arguments, you have to care about what their
 _names_ are in addition to what they're for. I do _not_ want to have to read
 code which uses named arguments. It's just more clutter and more intellectual
 overhead.
Sorry no, you don't *have* to. Nothing forces you to use them. And again named params are a help for /reading/. You & Don argue on a wrong basis, as if (1) they were forced on writing (2) they were supposed to be a feature at writing time. Even you who don't want it would benefit from them at times: on the opposite of what you say above, named params /remove/ intellectual/memory load from programmers' minds/brains. [It's like a fight against pocket calculators or the use of an encyclopedia to write a University thesis. (People should compute by hand and know all facts by heart.)] Denis -- _________________ vita es estrany spir.wikidot.com
Mar 01 2011
prev sibling next sibling parent reply Steven Wawryk <stevenw acres.com.au> writes:
On 01/03/11 08:08, Don wrote:
 2. It introduces a different syntax for calling a function.
 foo(4, 5);
 foo(x: 4, y: 5);
 They look different, but they do exactly the same thing. I don't like
 that redundancy.
So, out of consistency, I suppose you must be against foreach, scope(exit) and every other kind of lowering?
Feb 28 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 28 February 2011 23:24:00 Steven Wawryk wrote:
 On 01/03/11 08:08, Don wrote:
 2. It introduces a different syntax for calling a function.
 foo(4, 5);
 foo(x: 4, y: 5);
 They look different, but they do exactly the same thing. I don't like
 that redundancy.
So, out of consistency, I suppose you must be against foreach, scope(exit) and every other kind of lowering?
Except that they actually do something different. All adding the variable names really do in this case is document the name of the variable that each argument is tied to and enforce that the names you give are valid. While it does allow for some increased flexibility in cases where a function takes multiple default arguments, for the most part it's just documentation. For the most part, it's not actually doing anything for you. It's not even syntactic sugar. Now, obviously there are a number of people here who think that this compiler- verified documentation is worth having, but for the most part, that's all this is. It's not cutting down on boiler plate code or reducing how much you have to type to do a particular type of operation (in fact, it's increasing it). So, this is not at all comparable to foreach or scope or other features which use lowering to transform code. At most, this results in the re-ordering of arguments. It's a totally different type of feature. Really, named arguments are compiler-enforced documentation which allow you to do a couple of things that you wouldn't be able to do normally (re-order arguments and give arguments for parameters with default arguments without giving arguments for parameters earlier in the parameter list which have default arguments). They're not really anything fancier than that. So, they're not really comparable to foreach or scope statements. In my opinion (and Don's it seems), they just don't pull their weight, unlike features such as foreach and scope statements. We appear to be outnumbered however. - Jonathan M Davis
Feb 28 2011
parent Steven Wawryk <stevenw acres.com.au> writes:
On 01/03/11 18:25, Jonathan M Davis wrote:
 On Monday 28 February 2011 23:24:00 Steven Wawryk wrote:
 On 01/03/11 08:08, Don wrote:
 2. It introduces a different syntax for calling a function.
 foo(4, 5);
 foo(x: 4, y: 5);
 They look different, but they do exactly the same thing. I don't like
 that redundancy.
So, out of consistency, I suppose you must be against foreach, scope(exit) and every other kind of lowering?
Except that they actually do something different. All adding the variable names really do in this case is document the name of the variable that each argument is tied to and enforce that the names you give are valid. While it does allow for some increased flexibility in cases where a function takes multiple default arguments, for the most part it's just documentation. For the most part, it's not actually doing anything for you. It's not even syntactic sugar. Now, obviously there are a number of people here who think that this compiler- verified documentation is worth having, but for the most part, that's all this is. It's not cutting down on boiler plate code or reducing how much you have to type to do a particular type of operation (in fact, it's increasing it). So, this is not at all comparable to foreach or scope or other features which use lowering to transform code. At most, this results in the re-ordering of arguments. It's a totally different type of feature. Really, named arguments are compiler-enforced documentation which allow you to do a couple of things that you wouldn't be able to do normally (re-order arguments and give arguments for parameters with default arguments without giving arguments for parameters earlier in the parameter list which have default arguments). They're not really anything fancier than that. So, they're not really comparable to foreach or scope statements. In my opinion (and Don's it seems), they just don't pull their weight, unlike features such as foreach and scope statements. We appear to be outnumbered however. - Jonathan M Davis
Weight-pulling is the crux of the whole matter, and it is a highly subjective judgement. My comment was in response to "They look different, but they do exactly the same thing. I don't like that redundancy.". I was highlighting that redundancy like that is not in and of itself a bad thing. D uses it extensively and, as long as it's not frivolous, it contributes a great deal to the usability of the language. Back to the subjective judgement, it appears to me that the majority of people participating in this thread believe that the compiler-enforced documentation it provides *does* pull its weight.
Mar 01 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-02-28 22:38, Don wrote:
 But I still don't see the need for this feature. Aren't people using
 IDEs where the function signature (with parameter names) pops up when
 you're entering the function, and when you move the mouse over the
 function call?
 And if you really want to see them all the time, why not build that
 feature into the IDE?
 ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
That's very true. I'm used to that with Descent. On the other hand, I don't know how many editors that support this that also supports D. -- /Jacob Carlborg
Feb 28 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 28 February 2011 23:49:56 Jacob Carlborg wrote:
 On 2011-02-28 22:38, Don wrote:
 But I still don't see the need for this feature. Aren't people using
 IDEs where the function signature (with parameter names) pops up when
 you're entering the function, and when you move the mouse over the
 function call?
 And if you really want to see them all the time, why not build that
 feature into the IDE?
 ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
That's very true. I'm used to that with Descent. On the other hand, I don't know how many editors that support this that also supports D.
Unfortunately, D is going to have to become fairly mature before we have much in the way of really good IDE support. There _are_ options out there, but for the most part, when programming in D, I expect that the average programmer is forgoing the majority of benefits that a good IDE provides. So, while IDEs may help a great deal with certain things in the long run, I wouldn't expect many people to think that an IDE feature was a decent solution at this point (regardless of what you're talking about), since they're probably not using an IDE with such a feature at this point. - Jonathan M Davis
Mar 01 2011
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Tue, 2011-03-01 at 00:26 -0800, Jonathan M Davis wrote:
[ . . . ]
 Unfortunately, D is going to have to become fairly mature before we have =
much in=20
 the way of really good IDE support. There _are_ options out there, but fo=
r the=20
 most part, when programming in D, I expect that the average programmer is=
=20
 forgoing the majority of benefits that a good IDE provides. So, while IDE=
s may=20
 help a great deal with certain things in the long run, I wouldn't expect =
many=20
 people to think that an IDE feature was a decent solution at this point=
=20
 (regardless of what you're talking about), since they're probably not usi=
ng an=20
 IDE with such a feature at this point.
I wouldn't say mature, I would say has traction, or has market penetration. Basically the language can be as mature as Fortran, but still be unused and hence have no community wishing to create tooling. There is also the question of whether to fit in with something pre-existing or create something new. Eclipse, IntelliJ IDEA, Code::Blocks, NetBeans, Emacs, Vim? For good or ill, the metric seems to be Eclipse support: no Eclipse tooling means no users. C++ has dealt with this. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Mar 01 2011
parent Jacek Nowak <jaceknowak wp.eu> writes:
This thread caught my attention. As an outsider to D (tried it for some time,
but
went back to C++/Java anyway), I'd argue IDE can be a huge asset when it comes
to
promoting a language. Take a look at DevCpp, it is considered one of the worst
IDEs around because of lack of updates, but the mere fact that it comes packaged
with a compiler (old one) and click-to-build capability makes it very popular
even if people are aware of it's drawbacks. Visual C++ also comes packaged with
a
compiler and it's dumb easy to create a new project and compile&run it.
Yes, an experienced programmer is used to configuring his compiler, setting all
the paths, even writing his own makefiles, but if you are to bring new people to
D, I'd say a packaged IDE + compiler working out-of-box would be a great
feature.
Mar 01 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 03/01/2011 08:49 AM, Jacob Carlborg wrote:
 On 2011-02-28 22:38, Don wrote:
 But I still don't see the need for this feature. Aren't people using
 IDEs where the function signature (with parameter names) pops up when
 you're entering the function, and when you move the mouse over the
 function call?
 And if you really want to see them all the time, why not build that
 feature into the IDE?
 ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
That's very true. I'm used to that with Descent. On the other hand, I don't know how many editors that support this that also supports D.
And how does this feature help the reader and decode: f(1,"a",true); ? Denis -- _________________ vita es estrany spir.wikidot.com
Mar 01 2011
prev sibling next sibling parent reply Bekenn <leaveme alone.com> writes:
On 2/28/11 1:38 PM, Don wrote:
 1. It makes parameter names part of the API.
I wrote earlier that this would probably be the first time parameter names "leaked" into user code, but I was wrong. Jacob Carlborg has pointed out his library implementation of this feature: http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135 If you look through his implementation, you'll see that it uses the .stringof property to extract parameter names from the function definition. In essence, parameter names are /already/ part of the API, because code can be written that depends on them. And the fact that a library implementation exists specifically to facilitate the use of named arguments implies that code already /has/ been written that depends on parameter names. Like it or not, parameter names are already part of the API. Adding named arguments as a language feature doesn't change that.
Mar 01 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, March 01, 2011 11:22:17 Bekenn wrote:
 On 2/28/11 1:38 PM, Don wrote:
 1. It makes parameter names part of the API.
I wrote earlier that this would probably be the first time parameter names "leaked" into user code, but I was wrong. Jacob Carlborg has pointed out his library implementation of this feature: http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135 If you look through his implementation, you'll see that it uses the .stringof property to extract parameter names from the function definition. In essence, parameter names are /already/ part of the API, because code can be written that depends on them. And the fact that a library implementation exists specifically to facilitate the use of named arguments implies that code already /has/ been written that depends on parameter names. Like it or not, parameter names are already part of the API. Adding named arguments as a language feature doesn't change that.
You're talking about a third party library that's trying to hack in named arguments, not the language nor the standard library. The parameter names of a function are _not_ currently part of its signature. You could have a .di file without any parameter names or with totally different parameter names than the original .d file and it would have _zero_ effect on anything calling those functions. The function signature does _not_ include the name of its parameters - just their types. Adding named arguments would change that. - Jonathan M Davis
Mar 01 2011
parent reply Jim <bitcirkel yahoo.com> writes:
Jonathan M Davis Wrote:

 On Tuesday, March 01, 2011 11:22:17 Bekenn wrote:
 On 2/28/11 1:38 PM, Don wrote:
 1. It makes parameter names part of the API.
I wrote earlier that this would probably be the first time parameter names "leaked" into user code, but I was wrong. Jacob Carlborg has pointed out his library implementation of this feature: http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135 If you look through his implementation, you'll see that it uses the .stringof property to extract parameter names from the function definition. In essence, parameter names are /already/ part of the API, because code can be written that depends on them. And the fact that a library implementation exists specifically to facilitate the use of named arguments implies that code already /has/ been written that depends on parameter names. Like it or not, parameter names are already part of the API. Adding named arguments as a language feature doesn't change that.
You're talking about a third party library that's trying to hack in named arguments, not the language nor the standard library. The parameter names of a function are _not_ currently part of its signature. You could have a .di file without any parameter names or with totally different parameter names than the original .d file and it would have _zero_ effect on anything calling those functions. The function signature does _not_ include the name of its parameters - just their types. Adding named arguments would change that. - Jonathan M Davis
Neither are aliases signatures but they can still be imported. If the library writer choose to expose argument names in the .di file then I'd say they are part of the API.
Mar 02 2011
parent reply Don <nospam nospam.com> writes:
Jim wrote:
 Jonathan M Davis Wrote:
 
 On Tuesday, March 01, 2011 11:22:17 Bekenn wrote:
 On 2/28/11 1:38 PM, Don wrote:
 1. It makes parameter names part of the API.
I wrote earlier that this would probably be the first time parameter names "leaked" into user code, but I was wrong. Jacob Carlborg has pointed out his library implementation of this feature: http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135 If you look through his implementation, you'll see that it uses the .stringof property to extract parameter names from the function definition. In essence, parameter names are /already/ part of the API, because code can be written that depends on them. And the fact that a library implementation exists specifically to facilitate the use of named arguments implies that code already /has/ been written that depends on parameter names. Like it or not, parameter names are already part of the API. Adding named arguments as a language feature doesn't change that.
You're talking about a third party library that's trying to hack in named arguments, not the language nor the standard library. The parameter names of a function are _not_ currently part of its signature. You could have a .di file without any parameter names or with totally different parameter names than the original .d file and it would have _zero_ effect on anything calling those functions. The function signature does _not_ include the name of its parameters - just their types. Adding named arguments would change that. - Jonathan M Davis
Neither are aliases signatures but they can still be imported. If the library writer choose to expose argument names in the .di file then I'd say they are part of the API.
The library writer has no choice. Templates function implementation must be included in the .di file. This exposes the parameter names. The proposal introduces additional coupling between library code and user code, which is useless in the majority of cases. I can see the value in an opt-in annotation (*not* opt-out) for those problem domains where large numbers of function parameters are normal. But I would strongly oppose it in general.
Mar 02 2011
parent reply "Jason E. Aten" <j.e.aten gmail.com> writes:
I find this an interesting discussion.  Coming from writing alot of code in
language that makes extensive and
highly effective use of named arguments (R), I can say that optional named
arguments
(as in Lisp, and descendants like Python and R) do have big software
engineering benefits,
but also come with a substantial costs in terms of complexity of the
function call sequence.

That is, named arguments can be expensive in a typical interpreted
implementation
(probably one reason why R and Python are much slower to execute than the
other
interpreted languages), presumably because each function call has to
invoke hash
table lookups to determine the canonical formal position of each actual
argument, and deal with variadic
cases, to rearrange the order of the arguments to match expectations of the
callee.

Someone familiar with lisp compilers could probably tell you if the heavy
speed tax is intrinsic
or just the price of interpretation.

It would indeed be an interesting challenge to see if the compile-time
metaprogramming
features of D would allow one to include named arguments in an opt-in
fashion without speed reduction.

Jason

On Wed, Mar 2, 2011 at 6:16 AM, Don <nospam nospam.com> wrote:

 Jim wrote:

 Jonathan M Davis Wrote:

  On Tuesday, March 01, 2011 11:22:17 Bekenn wrote:
 On 2/28/11 1:38 PM, Don wrote:

 1. It makes parameter names part of the API.
I wrote earlier that this would probably be the first time parameter names "leaked" into user code, but I was wrong. Jacob Carlborg has pointed out his library implementation of this feature: http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135 If you look through his implementation, you'll see that it uses the .stringof property to extract parameter names from the function definition. In essence, parameter names are /already/ part of the API, because code can be written that depends on them. And the fact that a library implementation exists specifically to facilitate the use of named arguments implies that code already /has/ been written that depends on parameter names. Like it or not, parameter names are already part of the API. Adding named arguments as a language feature doesn't change that.
You're talking about a third party library that's trying to hack in named arguments, not the language nor the standard library. The parameter names of a function are _not_ currently part of its signature. You could have a .di file without any parameter names or with totally different parameter names than the original .d file and it would have _zero_ effect on anything calling those functions. The function signature does _not_ include the name of its parameters - just their types. Adding named arguments would change that. - Jonathan M Davis
Neither are aliases signatures but they can still be imported. If the library writer choose to expose argument names in the .di file then I'd say they are part of the API.
The library writer has no choice. Templates function implementation must be included in the .di file. This exposes the parameter names. The proposal introduces additional coupling between library code and user code, which is useless in the majority of cases. I can see the value in an opt-in annotation (*not* opt-out) for those problem domains where large numbers of function parameters are normal. But I would strongly oppose it in general.
Mar 02 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 02 Mar 2011 08:45:43 -0500, Jason E. Aten <j.e.aten gmail.com>  
wrote:

 I find this an interesting discussion.  Coming from writing alot of code  
 in
 language that makes extensive and
 highly effective use of named arguments (R), I can say that optional  
 named
 arguments
 (as in Lisp, and descendants like Python and R) do have big software
 engineering benefits,
 but also come with a substantial costs in terms of complexity of the
 function call sequence.

 That is, named arguments can be expensive in a typical interpreted
 implementation
 (probably one reason why R and Python are much slower to execute than the
 other
 interpreted languages), presumably because each function call has to
 invoke hash
 table lookups to determine the canonical formal position of each actual
 argument, and deal with variadic
 cases, to rearrange the order of the arguments to match expectations of  
 the
 callee.

 Someone familiar with lisp compilers could probably tell you if the heavy
 speed tax is intrinsic
 or just the price of interpretation.

 It would indeed be an interesting challenge to see if the compile-time
 metaprogramming
 features of D would allow one to include named arguments in an opt-in
 fashion without speed reduction.
Considering that calling a function with parameters by name directly translates at compile time to a function call by position, there should be zero speed impact. The interpretation of the parameter names, which is done at runtime for Python, would be done at compile time in D. -Steve
Mar 02 2011
next sibling parent reply Jim <bitcirkel yahoo.com> writes:
Steven Schveighoffer Wrote:

 On Wed, 02 Mar 2011 08:45:43 -0500, Jason E. Aten <j.e.aten gmail.com>  
 wrote:
 
 I find this an interesting discussion.  Coming from writing alot of code  
 in
 language that makes extensive and
 highly effective use of named arguments (R), I can say that optional  
 named
 arguments
 (as in Lisp, and descendants like Python and R) do have big software
 engineering benefits,
 but also come with a substantial costs in terms of complexity of the
 function call sequence.

 That is, named arguments can be expensive in a typical interpreted
 implementation
 (probably one reason why R and Python are much slower to execute than the
 other
 interpreted languages), presumably because each function call has to
 invoke hash
 table lookups to determine the canonical formal position of each actual
 argument, and deal with variadic
 cases, to rearrange the order of the arguments to match expectations of  
 the
 callee.

 Someone familiar with lisp compilers could probably tell you if the heavy
 speed tax is intrinsic
 or just the price of interpretation.

 It would indeed be an interesting challenge to see if the compile-time
 metaprogramming
 features of D would allow one to include named arguments in an opt-in
 fashion without speed reduction.
Considering that calling a function with parameters by name directly translates at compile time to a function call by position, there should be zero speed impact. The interpretation of the parameter names, which is done at runtime for Python, would be done at compile time in D. -Steve
In addition to that, named template arguments would allow you to create very customizable, yet lean types. It would be possible to parameterize all components. Basically, if you're not pleased with the default search algorithm or container type of a more complex object then you can specify your own.
Mar 02 2011
next sibling parent reply "Jason E. Aten" <j.e.aten gmail.com> writes:
On Wed, Mar 2, 2011 at 8:45 AM, Jim <bitcirkel yahoo.com> wrote:
 In addition to that, named template arguments would allow you to create
 very customizable, yet lean types. It would be possible to parameterize all
 components. Basically, if you're not pleased with the default search
 algorithm or container type of a more complex object then you can specify
 your own.
Interesting, I hadn't considered the benefits of template arguments with names as far as leanness of types. The best part of naming arguments for functions and methods, in my experience, is that if you add additional arguments to a method, it is a cheap change. I don't have to go and find and change all the client calls that have already been written. I can leave all of the existing source with client code untouched, and only specify the new parameter in the new invocation that wants to use the new functionality. I only have to recompile. Low maintenance. Nice.
Mar 02 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 02 Mar 2011 10:06:17 -0500, Jason E. Aten <j.e.aten gmail.com>  
wrote:

 On Wed, Mar 2, 2011 at 8:45 AM, Jim <bitcirkel yahoo.com> wrote:
 In addition to that, named template arguments would allow you to create
 very customizable, yet lean types. It would be possible to parameterize  
 all
 components. Basically, if you're not pleased with the default search
 algorithm or container type of a more complex object then you can  
 specify
 your own.
Interesting, I hadn't considered the benefits of template arguments with names as far as leanness of types. The best part of naming arguments for functions and methods, in my experience, is that if you add additional arguments to a method, it is a cheap change. I don't have to go and find and change all the client calls that have already been written. I can leave all of the existing source with client code untouched, and only specify the new parameter in the new invocation that wants to use the new functionality. I only have to recompile. Low maintenance. Nice.
This isn't as dynamic as you think. If you change a function's argument types or count, the client must recompile. However, their code shouldn't have to change. -Steve
Mar 02 2011
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/2/11 8:45 AM, Jim wrote:
 In addition to that, named template arguments would allow you to
 create very customizable, yet lean types. It would be possible to
 parameterize all components. Basically, if you're not pleased with
 the default search algorithm or container type of a more complex
 object then you can specify your own.
Got to say, named template arguments would be pretty awesome for policy-based design. There are other ways to deal with that (just accept variadic arguments and detect policies by signatures) but that's less clear for the client and aggravates the library writer. Andrei
Mar 02 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 03/02/2011 02:59 PM, Steven Schveighoffer wrote:
 On Wed, 02 Mar 2011 08:45:43 -0500, Jason E. Aten <j.e.aten gmail.com> wrote:

 I find this an interesting discussion. Coming from writing alot of code in
 language that makes extensive and
 highly effective use of named arguments (R), I can say that optional named
 arguments
 (as in Lisp, and descendants like Python and R) do have big software
 engineering benefits,
 but also come with a substantial costs in terms of complexity of the
 function call sequence.

 That is, named arguments can be expensive in a typical interpreted
 implementation
 (probably one reason why R and Python are much slower to execute than the
 other
 interpreted languages), presumably because each function call has to
 invoke hash
 table lookups to determine the canonical formal position of each actual
 argument, and deal with variadic
 cases, to rearrange the order of the arguments to match expectations of the
 callee.

 Someone familiar with lisp compilers could probably tell you if the heavy
 speed tax is intrinsic
 or just the price of interpretation.

 It would indeed be an interesting challenge to see if the compile-time
 metaprogramming
 features of D would allow one to include named arguments in an opt-in
 fashion without speed reduction.
Considering that calling a function with parameters by name directly translates at compile time to a function call by position, there should be zero speed impact. The interpretation of the parameter names, which is done at runtime for Python, would be done at compile time in D. -Steve
I had never thought at that, but I'm surprised: what prevents Python's "compiler" (say, a semantic phase after parsing) to check number and names of arguments. (Number seems not to be checked before runtime neither.) All required information is in the AST. For named params, Python could translate to position params just like D. This would certainly remove a relevant amount of runtime "speed-down", I guess. (Only type-check of builtin func args must remain at runtime.) Denis -- _________________ vita es estrany spir.wikidot.com
Mar 02 2011
parent reply Bekenn <leaveme alone.com> writes:
On 3/2/11 8:45 AM, spir wrote:
 I had never thought at that, but I'm surprised: what prevents Python's
 "compiler" (say, a semantic phase after parsing) to check number and
 names of arguments. (Number seems not to be checked before runtime
 neither.)
 All required information is in the AST. For named params, Python could
 translate to position params just like D. This would certainly remove a
 relevant amount of runtime "speed-down", I guess. (Only type-check of
 builtin func args must remain at runtime.)

 Denis
What follows is speculation; I'm not a Python programmer, but I am loosely familiar with the language. If I'm completely wrong, I'm sure someone will point it out: A Python "compiler" certainly can (and probably does) check function arguments, but the runtime is still heavily involved in argument passing. The complexity in Python is an artifact of how arguments are delivered at run-time: in a big (dynamically created, of course) dictionary. Essentially, The interpreter matches argument positions with parameter names -- at run time -- and then supplies those name/argument pairs as entries in the dictionary. (This is a logical view of the language, and may not precisely match implementations. For instance, I'd expect that "compiled" .pyc files throw out positional information ahead of time.) Looked at another way, *everything* is passed by name, not position; positional arguments are merely a shorthand notation. This is vastly different from how named arguments would be handled in D. D passes arguments by position -- end of story. Named arguments provide an alternative method of specifying the position of a given argument, which is determined by the compiler long before the linker or the runtime get involved.
Mar 02 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 02 Mar 2011 13:38:05 -0500, Bekenn <leaveme alone.com> wrote:

 On 3/2/11 8:45 AM, spir wrote:
 I had never thought at that, but I'm surprised: what prevents Python's
 "compiler" (say, a semantic phase after parsing) to check number and
 names of arguments. (Number seems not to be checked before runtime
 neither.)
 All required information is in the AST. For named params, Python could
 translate to position params just like D. This would certainly remove a
 relevant amount of runtime "speed-down", I guess. (Only type-check of
 builtin func args must remain at runtime.)

 Denis
What follows is speculation; I'm not a Python programmer, but I am loosely familiar with the language. If I'm completely wrong, I'm sure someone will point it out: A Python "compiler" certainly can (and probably does) check function arguments, but the runtime is still heavily involved in argument passing. The complexity in Python is an artifact of how arguments are delivered at run-time: in a big (dynamically created, of course) dictionary. Essentially, The interpreter matches argument positions with parameter names -- at run time -- and then supplies those name/argument pairs as entries in the dictionary. (This is a logical view of the language, and may not precisely match implementations. For instance, I'd expect that "compiled" .pyc files throw out positional information ahead of time.) Looked at another way, *everything* is passed by name, not position; positional arguments are merely a shorthand notation. This is vastly different from how named arguments would be handled in D. D passes arguments by position -- end of story. Named arguments provide an alternative method of specifying the position of a given argument, which is determined by the compiler long before the linker or the runtime get involved.
Not a python expert either, but I think you are right. Most dynamic languages are this way -- because you need that flexibility since a "compiled" script might not be recompiled after you change the API. And also, many dynamic languages allow changing the API mid-program (not sure about python). There would just be no way to determine this at compile time. -Steve
Mar 02 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 28/02/2011 21:38, Don wrote:
 But I still don't see the need for this feature. Aren't people using
 IDEs where the function signature (with parameter names) pops up when
 you're entering the function, and when you move the mouse over the
 function call?
 And if you really want to see them all the time, why not build that
 feature into the IDE?
 ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
That's exactly the point I was going to make, as soon as I saw the question/challenge of " HRESULT hr = m_Device.Present(null, null, null, null); Quick: What behavior does that third argument specify?" For such a fine grained and common situation, looking that API up anywhere outside the IDE (such as in a webpage, or in a file in a filesystem) in any serious development just seems to me very archaic. But hey, maybe I'm just spoiled by Java... :P -- Bruno Medeiros - Software Engineer
Mar 08 2011
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 28/02/2011 07:03, Bekenn wrote:
     HRESULT hr = m_Device.Present(pSourceRect: null, pDestRect: null,
hDestWindowOverride: null, pDirtyRegion: null);
One advantage is that it would encourage self-documenting code, partly because the meaning is clearer at the caller side, and partly because library programmers would be encouraged more to make parameter names meaningful. It also means that you don't have to remember which order the parameters of a function go in. Though this is only useful if you can remember what the parameters are called. For example, string search functions vary - needle/haystack, str/substr, search/seek, for/in. (OK, so some of these I've thought up on the spot, and for/in wouldn't work (nice as it may be) as they're keywords, but you get the idea.) Trouble is it would create fragility, as parameter names would become a new thing that can't be changed once decided without breaking existing code. So it would be important to get them right from the beginning, and there'll be a time when the feature has just been introduced during which library programmers are in the process of changing parameter names to something meaningful. But one way around that would be to support parameter aliases, which would also confer a few more benefits. Stewart.
Feb 28 2011
next sibling parent reply Bekenn <leaveme alone.com> writes:
On 2/28/11 4:50 PM, Stewart Gordon wrote:
 But one way around that would be to support
 parameter aliases, which would also confer a few more benefits.
Interesting idea. I think this might solve Jonathan Davis's main complaint; could you give an example of what syntax for that might look like?
Feb 28 2011
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 01/03/2011 01:29, Bekenn wrote:
 On 2/28/11 4:50 PM, Stewart Gordon wrote:
 But one way around that would be to support
 parameter aliases, which would also confer a few more benefits.
Interesting idea. I think this might solve Jonathan Davis's main complaint; could you give an example of what syntax for that might look like?
I don't know, but possibly void setColour(int colour alias color); and with a possibility of deprecating old names int find(string haystack deprecated alias s1, string needle deprecated alias s2); Stewart.
Feb 28 2011
next sibling parent Bekenn <leaveme alone.com> writes:
On 2/28/11 5:53 PM, Stewart Gordon wrote:
 I don't know, but possibly

 void setColour(int colour alias color);

 and with a possibility of deprecating old names

 int find(string haystack deprecated alias s1, string needle deprecated
 alias s2);
I think that could work; I don't mind the verbosity, given that the actual need for a parameter name alias should be exceedingly rare.
Feb 28 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/28/11 7:53 PM, Stewart Gordon wrote:
 On 01/03/2011 01:29, Bekenn wrote:
 On 2/28/11 4:50 PM, Stewart Gordon wrote:
 But one way around that would be to support
 parameter aliases, which would also confer a few more benefits.
Interesting idea. I think this might solve Jonathan Davis's main complaint; could you give an example of what syntax for that might look like?
I don't know, but possibly void setColour(int colour alias color); and with a possibility of deprecating old names int find(string haystack deprecated alias s1, string needle deprecated alias s2); Stewart.
Don't know about others, but I think this is exactly the point where my "meh" detector goes off. Andrei
Feb 28 2011
next sibling parent reply Bekenn <leaveme alone.com> writes:
On 2/28/2011 8:43 PM, Andrei Alexandrescu wrote:
 Don't know about others, but I think this is exactly the point where my
 "meh" detector goes off.
It *might* be worthwhile if it does indeed address Jonathan's concern about library writers not being able to change parameter names. I'm not sold that that's really such a big deal; I expect that parameter name aliases would be so rarely used as to disappear into obscurity. But I could be wrong.
Feb 28 2011
parent spir <denis.spir gmail.com> writes:
On 03/01/2011 05:52 AM, Bekenn wrote:
 On 2/28/2011 8:43 PM, Andrei Alexandrescu wrote:
 Don't know about others, but I think this is exactly the point where my
 "meh" detector goes off.
It *might* be worthwhile if it does indeed address Jonathan's concern about library writers not being able to change parameter names. I'm not sold that that's really such a big deal; I expect that parameter name aliases would be so rarely used as to disappear into obscurity. But I could be wrong.
Should we also have some mechanism to help lib writers and change type names, func names, member names...? Denis -- _________________ vita es estrany spir.wikidot.com
Mar 01 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:ikhtn9$2ea1$1 digitalmars.com...
 On 2/28/11 7:53 PM, Stewart Gordon wrote:
 On 01/03/2011 01:29, Bekenn wrote:
 On 2/28/11 4:50 PM, Stewart Gordon wrote:
 But one way around that would be to support
 parameter aliases, which would also confer a few more benefits.
Interesting idea. I think this might solve Jonathan Davis's main complaint; could you give an example of what syntax for that might look like?
I don't know, but possibly void setColour(int colour alias color); and with a possibility of deprecating old names int find(string haystack deprecated alias s1, string needle deprecated alias s2); Stewart.
Don't know about others, but I think this is exactly the point where my "meh" detector goes off.
std.algorithm has far worse signatures. The main problem I have with the above is that it only solves a barely-existent "problem".
Feb 28 2011
next sibling parent Bekenn <leaveme alone.com> writes:
On 2/28/2011 9:24 PM, Nick Sabalausky wrote:
 std.algorithm has far worse signatures. The main problem I have with the
 above is that it only solves a barely-existent "problem".
Right, exactly. Thinking about it some more, I don't really think the changing parameter name issue really justifies parameter name aliases.
Feb 28 2011
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/28/11 11:24 PM, Nick Sabalausky wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:ikhtn9$2ea1$1 digitalmars.com...
 On 2/28/11 7:53 PM, Stewart Gordon wrote:
 On 01/03/2011 01:29, Bekenn wrote:
 On 2/28/11 4:50 PM, Stewart Gordon wrote:
 But one way around that would be to support
 parameter aliases, which would also confer a few more benefits.
Interesting idea. I think this might solve Jonathan Davis's main complaint; could you give an example of what syntax for that might look like?
I don't know, but possibly void setColour(int colour alias color); and with a possibility of deprecating old names int find(string haystack deprecated alias s1, string needle deprecated alias s2); Stewart.
Don't know about others, but I think this is exactly the point where my "meh" detector goes off.
std.algorithm has far worse signatures. The main problem I have with the above is that it only solves a barely-existent "problem".
It's not the signature I was mehing about. Andrei
Feb 28 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 03/01/2011 01:50 AM, Stewart Gordon wrote:
 Trouble is it would create fragility, as parameter names would become a new
 thing that can't be changed once decided without breaking existing code.  So it
 would be important to get them right from the beginning, and there'll be a time
 when the feature has just been introduced during which library programmers are
 in the process of changing parameter names to something meaningful.  But one
 way around that would be to support parameter aliases, which would also confer
 a few more benefits.
That is a real concern, indeed, and the only rational point until now possibly interpretable against named parameters: once a lib is adopted, the feature freezes param names --just like type names, funcs names, member names, constant names, alias names and so on and so forth. On the other hand, this will hopefully prevent lib authors using meaningless/helpless names from the start on ;-) It may even help & promote de facto or discussed conventions on param names (ideally, one would be able to guess half of them from the /meaning/ of parameters) Denis -- _________________ vita es estrany spir.wikidot.com
Mar 01 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Feb 2011 19:50:44 -0500, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 On 28/02/2011 07:03, Bekenn wrote:
     HRESULT hr = m_Device.Present(pSourceRect: null, pDestRect: null,  
 hDestWindowOverride: null, pDirtyRegion: null);
One advantage is that it would encourage self-documenting code, partly because the meaning is clearer at the caller side, and partly because library programmers would be encouraged more to make parameter names meaningful. It also means that you don't have to remember which order the parameters of a function go in. Though this is only useful if you can remember what the parameters are called. For example, string search functions vary - needle/haystack, str/substr, search/seek, for/in. (OK, so some of these I've thought up on the spot, and for/in wouldn't work (nice as it may be) as they're keywords, but you get the idea.) Trouble is it would create fragility, as parameter names would become a new thing that can't be changed once decided without breaking existing code. So it would be important to get them right from the beginning, and there'll be a time when the feature has just been introduced during which library programmers are in the process of changing parameter names to something meaningful. But one way around that would be to support parameter aliases, which would also confer a few more benefits.
This is probably the worse concern, because right now, phobos has been created without the intention that parameter names will be used at the call site. Despite all the concern, I believe phobos has been naming parameters just fine. If there are any poorly named parameters, they either a) aren't worth worrying about or b) should be renamed anyways (even if named parameter calling is not introduced). I think the alias idea is too much... -Steve
Mar 01 2011
prev sibling parent reply "Joel C. Salomon" <joelcsalomon gmail.com> writes:
(De-lurking; I've been interested in D for a while, but my programming
is almost exclusively in C -- generally C99.)

Does D have the equivalent of C99's "designated initializers"?

Were I to attempt something like this in C, the code would go something
like this:

    int foo(int height, int width);
    struct _foo_args {
        int height; int width;
    };
    #define foo(...) \
        foo((struct _foo_args){__VA_ARGS__}.height, \
            (struct _foo_args){__VA_ARGS__}.width)

at which point each of these calls:

    foo(a, b);
    foo(.height = a, .width = b);
    foo(.width = b, .height = a);

have the same effect.

I'll readily admit this is *not* pretty, and likely more effort than
it's worth, but is will work.

Are D's compile-time operations not capable of something at *least* this
powerful?

--Joel
Mar 06 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 06 March 2011 16:57:17 Joel C. Salomon wrote:
 (De-lurking; I've been interested in D for a while, but my programming
 is almost exclusively in C -- generally C99.)
 
 Does D have the equivalent of C99's "designated initializers"?
 
 Were I to attempt something like this in C, the code would go something
 like this:
 
     int foo(int height, int width);
     struct _foo_args {
         int height; int width;
     };
     #define foo(...) \
         foo((struct _foo_args){__VA_ARGS__}.height, \
             (struct _foo_args){__VA_ARGS__}.width)
 
 at which point each of these calls:
 
     foo(a, b);
     foo(.height = a, .width = b);
     foo(.width = b, .height = a);
 
 have the same effect.
 
 I'll readily admit this is *not* pretty, and likely more effort than
 it's worth, but is will work.
 
 Are D's compile-time operations not capable of something at *least* this
 powerful?
D doesn't have macros. It has incredibly powerful templates as well as string mixins, but no macros. So, what D has tends to be very powerful, but there are times when it's more verbose to use than a C macro might be, and there are some things that you can do with C macros that you can't readily do in D (though there are a lot of things that yo ucan do with D templates that you could never do with C macros or even C++ templates - or if you can, it's a _lot_ harder in C++). It's a lot safer and less error-prone that way though. In this case, you could do something like this: int width; int height; func(width = 2, height = 7); That _is_ a bit wasteful though in that it's assigning to local variables which are likely never used after that. Regardless, I don't think that you can do something quite like what you're trying to do. If nothing else, I don't think that D has anything like C99's designated initializers. It has constructors. - Jonathan M Davis
Mar 06 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Joel C. Salomon:

 Does D have the equivalent of C99's "designated initializers"?
D2 currently allows code like this (but I don't know if this will be deprecated, for me sometimes is not easy to remember all things that will be deprecated): struct Foo { int x, y, z; } Foo f1 = { x:1, y:2 }; Foo f2 = { x:1, z:2 }; void main() {} Bye, bearophile
Mar 06 2011