Pretty please: Named arguments

[Steven Schveighoffer]

On Mon, 28 Feb 2011 19:50:44 -0500, Stewart Gordon <smjg_1998 at 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