Re: [PATCH] libstdc++: Simplify range adaptors' forwarding of bound args when possible

[Jonathan Wakely <jwakely@redhat.com>]

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?