On Tue, Oct 11, 2016 at 10:54 AM, Martin Sebor <mse...@gmail.com> wrote:
> To close the loop on this thread, although there was mild support
> for both of these conventions there were also objections to both,
> including a suggestion for an alternative to the "/*foo_p=*/" style
> that would be preferred by most people who responded.
>
> With that I don't have the sense that there is consensus to adopt
> either style as conventions for GCC code.
>
> Jason and Jeff (and other reviewers), what does this mean for those
> of us submitting patches? Do we discontinue using the "/*foo_p=*/"
> style in the C++ front end or should we train ourselves to remember
> to use it there but nowhere else?
I still like the comments when it's not clear what the arguments mean
without looking at the callee, no matter the type of the argument. I
would be happy with a patch that changed some of the booleans to enums
instead.
Jason
> On 10/03/2016 05:48 PM, 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 pointed out to Jason that in another code review, Jeff asked
>> to remove the same comment from the middle-end [1]. In the
>> interest of consistency Jason and I thought I should bring this
>> up for discussion so we can all be clear on whether or not this
>> is something worth standardizing and documenting.
>>
>> As a separate question, in the same discussion I mention to Jason
>> a convention that I myself have found useful where the value of
>> a default argument is indicated in a comment in a function
>> definition that is declared elsewhere to take one, e.g., like so:
>>
>> // In some header:
>> void foo (int, int, bool = -1);
>>
>> // In some .c file:
>> void foo (int x, int y, bool bar_p /* = false */)
>> {
>> ...
>> }
>>
>> Jason thought this would be a good convention. Is there any
>> interest in/support for adopting it?
>>
>> Thanks
>> Martin
>>
>> [1] https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00354.html
>> [2] https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01469.html
>
>
