[RFC] Update coding conventions to restrict use of non-const references

[Aldy Hernandez]

On 07/16/2018 04:19 AM, Richard Sandiford wrote:
> Aldy Hernandez <aldyh@redhat.com> writes:
>> On Thu, Jul 12, 2018 at 1:41 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>>
>>> On Thu, 12 Jul 2018 at 11:41, Richard Sandiford wrote:
>>>> +Only use non-constant references in the following situations:
>>>> +</p>
>>>> +
>>>> +<ul>
>>>> +<li>when they are necessary to conform to a standard interface, such as
>>>> +the first argument to a non-member <code>operator+=</code></li>
>>>
>>> And the return value of such operators (which also applies to member
>>> operators, which is the more conventional way to write compound
>>> assignment operators).
>>>
>>>> +<li>in a return value, when providing access to something that is known
>>>> +to be nonnull</li>
>>>> +</ul>
>>>> +
>>>> +<p>
>>>> +In other situations the convention is to use pointers instead.
>>>> +</p>
>>>> +
>>>> +<blockquote>
>>>> +<pre><code>HOST_WIDE_INT do_arith (..., bool *overflow);   // OK
>>>> +HOST_WIDE_INT do_arith (..., bool &overflow);   // Please avoid
>>>
>>> I understand the objection to using references for out parameters (an
>>> alternative to pointers is to return a struct with the wide int result
>>> and the overflow flag), but ...
>>
>> Putting everything in a new struct is just going through more hoops to
>> avoid a common language idiom that everyone in C++ is used to.
>>
>>>
>>>> +int *elt = &array[i];  // OK
>>>> +int &elt = array[i];   // Please avoid
>>>
>>> ... this seems unnecessary. If the function is so long that the fact
>>> elt is a reference can easily get lost, the problem is the length of
>>> the function, not the use of a reference.
>>
>> Agreed.
>>
>> Richard (Sandiford), this really looks like going out of your way to
>> enforce a personal style issue across the entire code base.  It's sad
>> that we try to come up with new ways to make it even harder for new
>> developers to contribute to GCC.
> 
> It's not enforcing a personal style issue so much as trying to stop
> the source base from becoming even more inconsistent, admittedly in one
> particular area only.
> 
> Before the switch to C++, GCC was one of the most consistent source
> bases I'd seen (more so even than LLVM IMO, having worked on both).
> It's clearly less so now.  The problem isn't just legacy C-era code vs.
> new C++ code, but different styles being used for the C++ code.

I certainly appreciate your concern, and the time you have taken to 
amend the guidelines.  However, perhaps we should get consensus here, as 
this is an issue that affects us all.

> 
> (It was interesting that Martin complained earlier in the thread about
> how inconsistent GCC was.  I imagine that's the impression that new
> developers would have now, rather than being glad that they can use
> references to return things.)
> 
> In the case of pointers vs. reference parameters for returning values,
> we have a clear precendent from the C days and very few existing C++
> functions that deviate from it.  So if we were going to pick one,
> it seemed obvious which we should pick.  Perhaps there's an argument
> that eventually everything will move over to the new style due to
> natural churn, but I think another half-transition is far more likely.

Heh.  I would definitely prefer moving to the new style ;-).

> 
> But weight of opinion definitely seems to be against adding that rule
> to the standards, so I'll drop the patch.

Again, I have a preference for non constant references if it makes the 
code easier to read, but I don't feel so strongly as to fight about it, 
especially if there is consensus going the other way.

I welcome more discussion on this, and will gladly accept what the 
majority agrees on.

Aldy