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

[Gor Gyolchanyan]

Naming is much less error-prone, then positioning, because change in
position is much less obvious (especially for parameters of the same
type).
When you write a class or a function you also need to come up with a
name, but you don't think of it as being forced to think ahead.
You'll always need to think ahead no matter what you do. A
sufficiently easy named parameter mechanism can easily allow you to
deprecate names if necessary.
Moreover, disallowing positional parameters is absolutely not
necessary, because it would lead to ugly code:

sin(5)
sin(x : 5)

I think the best idea would be to allow both named and positional, but
disallow mixing them. That is, you can either pass all your parameters
by name or by position.

int[2] makeAPoint(int x, int y) { return [x, y]; }

unittest
{
    auto a0 = makeAPoint(5, 7); // valid
    auto a1 = makeAPoint(x : 5, y : 7); // valid
    auto a2 = makeAPoint(5, y : 7); // invalid
    auto a2 = makeAPoint(x : 5, 7); // invalid
}

I really don't see any benefits in allowing mixed calls. in those
cases you might as well encapsulate the parameters in a structure.

On Thu, Dec 29, 2011 at 12:08 PM, Don <nospam at nospam.com> wrote:
> On 29.12.2011 04:48, David Nadlinger wrote:
>>
>> On 12/29/11 3:46 AM, Timon Gehr wrote:
>>>
>>> My point is, without named arguments you can improve the names at any
>>> time. With named arguments, you are stuck and have to get it right
>>> upfront.
>>
>>
>> My point is, without positional arguments you can improve the ordering
>> at any time. With positional arguments, you are stuck and have to get it
>> right upfront.
>>
>> David
>
>
> That's rubbish! Unless you plan to disallow positional arguments...



-- 
Bye,
Gor Gyolchanyan.