Flag proposal

[KennyTM~]

On Jun 14, 11 16:39, so wrote:
> On Tue, 14 Jun 2011 11:23:12 +0300, KennyTM~ <kennytm at gmail.com> wrote:
>
>> On Jun 14, 11 14:46, so wrote:
>>> On Tue, 14 Jun 2011 09:18:42 +0300, KennyTM~ <kennytm at gmail.com> wrote:
>>>
>>>> I'd rather have no reordering and allow hybrid call. Named argument is
>>>> useful for specifying the nature of an argument. If the type is clear
>>>> for all but one argument, the rest is just noisy redundant info.
>>>
>>> fun(bool, bool, bool, bool, bool...)
>>> Isn't the type clear for every argument here?
>>>
>>
>> By "type" I mean the purpose of an argument, e.g. the first 'int' in
>> MoveWindow is an x-coordinate, the second is a y-coordinate, etc.
>> Sorry I don't know of a better term. When what one argument does is
>> clear for the caller, forcing NA on it just annoys the programmer.
>
> This is the whole point of NAs, it is not clear, you need to check the
> function definition whenever you read the call.
>

And yet, with loc.x, myWin.width etc, you don't need to check the 
definition to know those should be coordinates and widths.

>>>> e.g.
>>>>
>>>> MoveWindow(hWnd, loc.x, loc.y, myWin.width, myWin.height,
>>>> bRepaint:true);
>>>>
>>>> is no worse than
>>>>
>>>> MoveWindow(hWnd:hWnd, X:loc.x, Y:loc.y,
>>>> nWidth:myWin.width, nHeight:myWin.height, bRepaint:true);
>>>
>>> Reordering is important an example:
>>>
>>> fun(int a, int b=2, int c=3)
>>> If you want to name c but not b what are you going to do?
>>>
>>
>> That's skipping, not really reordering. 'a' still precedes 'c'. Also,
>> I'm not against reordering, but I'm against using reordering as a
>> reason to abandon hybrid.
>
> It is not a reason to abandon hybrid, it is a consequence of abandoning it.
>

You don't need to abandon hybrid to enable reordering. Ary's suggestion, 
for example, allows positional and named arguments to coexist.

>>> Named arguments isn't something to save typing.
>>> Also the first version of the MoveWindow indeed worse than the second,
>>> which again i think requires no explanation.
>>
>> No, please explain. What does the extra hWnd, X, Y, nWidth, nHeight
>> buy, when the respective arguments already show what they are?'
>
> Matching, with fun(x:x, y:y) or fun(y:y, x:x) you are done, you don't
> ever need to check function definition again.
> With your reasoning you don't need named arguments at all.
>

Why do you need to check the function definition when you see 'moveTo(x, 
y)'?

> 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);