On 02/28/2011 01:41 PM, Michel Fortin wrote:
On 2011-02-28 02:03:46 -0500, Bekenn <leav...@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
