Flag proposal

[KennyTM~]

On Jun 15, 11 00:45, so wrote:
> On Tue, 14 Jun 2011 15:18:09 +0300, KennyTM~ <kennytm at gmail.com> wrote:
>
>>> loc.x on the caller side, it has no idea about function signature, and
>>> you don't know if it was 10th or 2nd argument in function.
>>>
>>> // definition
>>> fun(int x, int y) {
>>> }
>>>
>>> // call
>>> fun(x, y) // you need to check the definition if you think something
>>> wrong with parameters the second time you come here
>>> fun(y, x) // same
>>> fun(x:x, y:y) // you know there is nothing wrong with parameters
>>> fun(y:y, x:x) // same
>>>
>>
>> If you have no idea about the function signature, you have no idea
>> about the parameter names either.
>
> I think you are just resisting here, if you write a call once with named
> arguments, you documented it in place, the next time you visit this call
> all you need to see is in the call site.
>

I'm just bringing up the fact. Why would you need to check the function 
signature when reading

     MoveWindow(hWnd, loc.x, loc.y, myWin.width, myWin.height,
                bRepaint:true);

? It's clear what each argument does. If you feel the need of 
duplicating the same information, fine, write

     MoveWindow(hWnd:hWnd, X:loc.x, Y:loc.y,
                nWidth:myWin.width, nHeight:myWin.height, bRepaint:true);

in your code. But don't make it mandatory, it's a waste of time and 
space when the writer just wants to clarify that 'true' is a bRepaint.

>> You see the difference between variables and generic constants?
>>
>> RECT bounds;
>> GetWindowRect(hWnd, &bounds);
>>
>> writeln("Please enter the coordinates.");
>> auto x = readln().chomp().to!int();
>> auto y = readln().chomp().to!int();
>> auto width = bounds.right - bounds.left;
>> auto height = bounds.bottom - bounds.top;
>>
>> MoveWindow(hWnd, x, y, width, height, bRepaint:true);
>> vs.
>>
>> writeln("Resetting window dimensions");
>> ...
>> MoveWindow(hWnd, X:0, Y:0, nWidth:800, nHeight:600, bRepaint:true);
>>
>> Named arguments provides clarification when the argument itself (e.g.
>> 0, false, true) is meaningless. But with a variable which itself
>> provides a meaning, forcing named argument on _every_argument_passed_
>> is just annoying.
>
> Looks like i am just repeating myself but i don't understand how is
> pssing constants meaningless and variables, and why do you even need
> named arguments for those?
>
> enum x=...
> enum y=...
> ...
> fun(x, y)
>

If you want to disregard named argument, why go the complicated route 
and define enums? You could do as well

     fun(/*x*/0, /*y*/0);

(and yes I'm currently using it.) But the point is it's ugly. Heck why 
do we need to defend NA. My point is only "hybrid should be allowed if I 
want to".

>> Yet all well-known languages that support named arguments that support
>> reordering also support hybrid. (C# 4, VB 6, Python, CLisp, ...)
>
> This is not an argument.

Neither is 'Just search "named arguments" and first thing you'd see is 
calls with all arguments named, no exception.'

Maybe another argument: D's static struct initializer already supports 
hybrid and reordering. Extending that to function arguments is natural.

------------------------------------
struct S { int x; int y; }
void main() {
     S s0 = {4, 5};
     S s1 = {x:4, 5};
     S s2 = {4, y:5};
     S s3 = {x:4, y:5};
//  S s4 = {y:4, 5};    // error
     S s5 = {y:5, x:4};
}
------------------------------------