Flag proposal

[so]

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

> 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?

>> 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.
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.