Pretty please: Named arguments

[Gareth Charnock]

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:

http://docs.wxwidgets.org/trunk/classwx_frame.html#01b53ac2d4a5e6b0773ecbcf7b5f6af8

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