Re: style convention: /*foo_p=*/ to annotate bool arguments

[David Brown <david at westcontrol dot com>]

On 04/10/16 12:41, Jonathan Wakely wrote:
> On 4 October 2016 at 10:21, David Brown wrote:
>> On 04/10/16 01:48, Martin Sebor wrote:
>>> In a recent review Jason and I discussed the style convention
>>> commonly followed in the C++ front end to annotate arguments
>>> in calls to functions taking bool parameters with a comment
>>> along the lines of
>>>
>>>   foo (1, 2, /*bar_p=*/true);
> 
> I like this convention at the call-site, otherwise "true" or "false"
> doesn't tell you much and you have to look at the declaration.

Far and away the best solution would be for C++ to support named
parameters or named arguments:

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4172.htm>

Then you could write:

	foo(1, 2, bar_p: true);

You could also write

	foo(y: 2, bar_p: true, x: 1)

and get the same call.

It is always much better if you can put something in code rather than a
comment.

> 
> IMHO even better is to not use bool and define an enumeration type, so
> the call site has something unambiguous like foo (1, 2, yes_bar) or
> foo (1, 2, no_bar).

Sometimes that is the case, other times it is inconvenient to have to
create a new type just for that purpose.

A nice idea would be to extend n4172 so that you could declare foo as:

void foo(int x, int y, explicit bool bar_p = true);

This would mean that you could call foo as:

	foo(1, 2);
	foo(x: 1, y: 2, bar_p: true);
	foo(y: 2, bar_p: true, x: 1)
	foo(1, 2, bar_p: true);

but /not/ as
	
	foo(1, 2, true);

as the "explicit" would mean that you can /only/ use a named parameter here.

<snip>
	
>>
>> If
>> it is relevant, perhaps because you want to emphasize a particular path
>> for speed, then a comment might be useful - but it is better to use code
>> (like __builtin_expect) than comments.  Comments make it easy to be
>> inconsistent, and are unnecessary when the same information is easily
>> available by looking at the header (modern IDE's make that quick).
> 
> That's not very relevant if GCC developers don't use modern IDEs :-)
> 

A few years ago, people would have thought the same about a suggestion
to move gcc development to C++ !