On 14/05/21 14:27 -0400, Patrick Palka via Libstdc++ wrote:
r11-8053 rewrote the range adaptor implementation in conformance with
P2281, making partial application act like a SFINAE-friendly perfect
forwarding call wrapper. Making SFINAE-friendliness coexist with
perfect forwarding here requires adding fallback deleted operator()
overloads (as described in e.g. section 5.5 of wg21.link/p0847r6). But
unfortunately, as reported in PR100577, this necessary technique of
using of deleted overloads regresses diagnostics for ill-formed calls to
partially applied range adaptors in GCC.
Although GCC's diagnostics can arguably be improved here by having the
compiler explain why the other candidates weren't viable when overload
resolution selects a deleted candidate, we can also largely work around
this on the library side (and achieve more concise diagnostics than by
a frontend-side improvement alone) if we take advantage of the
observation that not all range adaptors need perfect forwarding call
wrapper semantics, in fact only views::split currently needs it, because
all other range adaptors either take no extra arguments or only
arguments that are expected to be freely/cheaply copyable, e.g. function
objects and integer-like types. (The discussion section of P2281 goes
into detail about why views::split is special.)
To that end, this introduces opt-in flags for denoting a range adaptor
as having "simple" extra arguments (in the case of a range adaptor
non-closure) or having a "simple" call operator (in the case of a range
adaptor closure). These flags are then used to conditionally simplify
the operator() for the generic _Partial and _Pipe class templates, down
from needing three overloads thereof (including one defined as deleted)
to just needing a single overload. The end result is that diagnostic
quality is restored for all adaptors except for views::split, and
diagnostics for the adaptors are generally made more concise since
there's only a single _Partial/_Pipe overload to diagnose instead of
three of them.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/11?
OK for trunk and 11.
Is there any benefit in using [[no_unique_address]] for
_Partial::_M_args too?
