Pretty please: Named arguments

[spir]

On 02/28/2011 01:41 PM, Michel Fortin wrote:
> On 2011-02-28 02:03:46 -0500, Bekenn <leaveme at alone.com> said:
>
>> Potential problems: The only problems I can foresee here are variations on
>> the situation when there are two (or more) versions of a function with the
>> same number, type, and names of parameters, but in non-matching order, like
>> this:
>>
>> void func(int a, char b);
>> void func(char b, int a);
>>
>> In such a case, the compiler should diagnose an error if named arguments are
>> employed.
>>
>> Thoughts?
>
> Another problem is what happens if you override a function by using different
> parameter names. For instance:
>
> class A {
> void func(int foo);
> }
> class B : A {
> void func(int bar);
> }
>
> Currently, the above is allowed. Would it now become an error?
>
> I think it'd be much easier to support named arguments if we didn't allow
> reordering. I know I'm stripping the proposal from one of its main benefits,
> but I think the essence remains. This would make the rather common pattern of
> adding a comment for each argument compiler-verifiable without disrupting
> things too much:
>
> draw(null, // text
> null, // font
> 12, // size
> 0, // flags
> );
>
> draw(text: null,
> font: null,
> size: 12,
> flags: 0);
>
> It would be implemented as a check for equality of the argument names after
> overload resolution. No ABI change, no interaction with overloading, just an
> extra check that if an argument name is specified it must match the one in the
> declaration.

+++ Make things simple!
Since positional arguments is the main & historic parameter-passing method, 
just keep order.
For me, allowing unordered arguments is just a (somewhat nice) side-effect of 
naming. The huge gain by far is "semantic unload" talen out of programmer 
shoulders ; and self-documentation. Just like in your example.
The latter point (self-doc) also has a big benefit in terms of language 
learning: if code samples use named args, then understanding and memorising 
common funcs and other tools can be far easier.

> There'd still be a funny interaction with overriding (see my first example),
> but you can always leave your argument unnamed if the definition keep changing
> the name in unpredictable ways.

I would say: name mismatch --> error. Meaning "x.func(foo=1)" throws if method 
lookup ends up selecting "B.func" (meaning x is a B); conversely 
"x.func(bar=1)" throws if method lookup ends up selecting "A.func" (meaning x 
is an A but not a B).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com