Named Parameters (Was: A nice way to step into 2012)

[Timon Gehr]

On 12/29/2011 02:04 AM, Derek wrote:
> On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr <timon.gehr at gmx.ch> wrote:
>
>> Having parameter names contribute to the interface means that all
>> developers need to spend time thinking about the best possible names
>> for their function parameters.
>
> And that's a bad thing, right?

If the time was better spent at creating functionality, yes.

http://www.digitalmars.com/d/archives/digitalmars/D/Rename_std.string.toStringz_138740.html

http://www.digitalmars.com/d/archives/digitalmars/D/Fixing_enum_names_in_Phobos_141507.html

http://www.digitalmars.com/d/archives/digitalmars/D/std.getopt_suggestion_145648.html#N145648

http://www.digitalmars.com/d/archives/digitalmars/D/renamepalooza_time_127446.html

...
etc.


>
> Named parameters do have the issue that once released, it is can be
> costly to change the names. It therefore is important that library
> developers take enough time to consider parameter names, much in the
> same manner as they are currently consider existing exposed names.
>
> To assist those developers, a name deprecation facility could be
> introduced to alert users of pending removal of old names. This would of
> course only be of interest to those developers who choose to use named
> parameters in their code.
>
> There is a similar issue with positional parameters; once released, the
> library developer would be unwise to alter the order of parameters. But
> somehow, we have managed to educate ourselves so as to (mostly) avoid
> this problem.
>
>
> In general, I'd support optional named parameters and would encourage
> their usage in those situations where it makes source code more
> understandable to other readers.
>

I am indifferent whether or not to add them.