On Mon, Jul 16, 2018 at 11:48 AM Aldy Hernandez <al...@redhat.com> wrote: > > > > On 07/16/2018 04:19 AM, Richard Sandiford wrote: > > 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. > > 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.
The only thing I would insist on is consistency within a group of API functions or even within related APIs (poly-int vs. wide-int for example). Richard. > > Aldy
