On Fri, 6 Mar 2020, Jonathan Wakely wrote: > On 05/03/20 11:02 -0500, Patrick Palka wrote: > > This works around PR 93978 by avoiding having to instantiate ranges::empty() > > when checking the constraints of view_interface::operator bool(). When > > ranges::empty() has an auto return type, then we must instantiate it in > > order to > > determine whether the requires expression { ranges::empty(_M_derived()); } > > is > > well-formed. But this means instantiating view_interface::empty() and hence > > view_interface::_M_derived(), all before we've yet deduced the return type > > of > > join_view::end(). (The reason view_interface::operator bool() is needed in > > join_view::end() in the first place is because in this function we perform > > direct initialization of join_view::_Sentinel from a join_view, and so we > > try to > > find a conversion sequence from the latter to the former that goes through > > this > > conversion operator.) > > > > Giving ranges::empty() a concrete return type of bool should be safe > > according > > to [ranges.prim.empty]/4 which says "whenever ranges::empty(E) is a valid > > N.B. [range.prim.empty] in the commit log here please, not "ranges."
Fixed. > > > expression, it has type bool." > > Right, I don't know why I didn't make it just return bool anyway. > Probably because I was copy&pasting _Begin for each of those other > range access CPOs. > > This way we've become aware of the danger of using deduced return > types, and so can audit the other cases. It seems that all of the other range access CPOs (since they are each defined with a deduced return type) have some form of this issue: using them as an unevaluated operand may cause more templates to get instantiated than when using the corresponding expression-equivalent expression. In this specific case, checking the constraint requires { ranges::empty(_M_derived()); } requires instantiating the body of _Derived::empty(), whereas checking the expression-equivalent constraint requires { _M_derived().empty(); } doesn't. If this discrepancy is important, then it seems we need to avoid using a deduced return type in the definitions of each of these CPOs. Is this worth doing? > > > This fixes the test case in PR 93978 when compiling without -Wall, but with > > -Wall > > the test case still fails due to the issue described in PR c++/94038, I > > think. > > I still don't quite understand why the test case doesn't fail without -O. > > Still a small improvement. > > OK for master, thanks.