Flag proposal

[KennyTM~]

On Jun 14, 11 19:11, so wrote:
> On Tue, 14 Jun 2011 12:58:30 +0300, KennyTM~ <kennytm at gmail.com> wrote:
>
>> And yet, with loc.x, myWin.width etc, you don't need to check the
>> definition to know those should be coordinates and widths.
>
> 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.

>> You don't need to abandon hybrid to enable reordering. Ary's
>> suggestion, for example, allows positional and named arguments to
>> coexist.
>
> Allows reordering by introducing two new order restrictions which i
> still had trouble understanding, sorry Ary :)
>
>> Why do you need to check the function definition when you see
>> 'moveTo(x, y)'?
>
> Same question, why do you need named arguments?
>

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.

>>> enum bRepaint=true;
>>> MoveWindow(... bRepaint)
>>
>> Non sequitur. In my MoveWindow example hWnd, loc and myWin are assumed
>> to be variables you got from elsewhere. The names of these variables
>> already provide the semantics to the readers, making NA for those
>> arguments redundant. If they were constants it's nothing wrong with
>>
>> MoveWindow(hWnd, X:0, Y:0, nWidth:200, nHeight:200, bRepaint:true);
>
> Again, they are variables you get on the caller side, they got no idea
> about function signature.

See above.

> Also i don't understand why some think allowing hybrid calls has any
> merit. Just search "named arguments" and first thing you'd see is calls
> with all arguments named, no exception. Allowing unnamed arguments and
> named arguments in one call doesn't make any sense to me, it is almost
> opposite to the reasons named arguments designed for, you don't even
> need to talk about its drawbacks like the complications and confusions.

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