Aldy Hernandez <al...@redhat.com> writes: > On Thu, Jul 12, 2018 at 1:41 PM Jonathan Wakely <jwakely....@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. (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. But weight of opinion definitely seems to be against adding that rule to the standards, so I'll drop the patch. Thanks, Richard
