Pretty please: Named arguments

[Stewart Gordon]

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.