On Wed, 21 Aug 2024 at 13:58, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk? I'm not
> sure if the current specification of 'projected' strictly speaking
> allows for this optimization, but it seems like a natural one that
> should be allowed.
Yeah, I can't see any conformance problems with doing this. I'm sure
somebody smarter than me will point it out if there's a problem, so
let's try it and see.
OK for trunk, thanks.
>
> -- >8 --
>
> Algorithms that are generalized to take projections usually default the
> projection to std::identity, which really means no projection at all.
> In that case, I believe we could shortcut the projection logic to return
> the indirectly readable type unchanged rather than a wrapped version of
> it. This should help with compile times especially after P2609R3 which
> made the indirect invocability concepts more expensive to check when
> projections are in the picture.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/iterator_concepts.h (__detail::__projected):
> Define partial specialization for a std::identity projection.
> ---
> libstdc++-v3/include/bits/iterator_concepts.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/libstdc++-v3/include/bits/iterator_concepts.h
> b/libstdc++-v3/include/bits/iterator_concepts.h
> index d849ddc32fc..642c709fee0 100644
> --- a/libstdc++-v3/include/bits/iterator_concepts.h
> +++ b/libstdc++-v3/include/bits/iterator_concepts.h
> @@ -803,6 +803,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> using __projected_Proj = _Proj;
> };
> };
> +
> + // Optimize the common case of the projection being std::identity.
> + template<typename _Iter>
> + struct __projected<_Iter, identity>
> + { using __type = _Iter; };
> } // namespace __detail
>
> /// [projected], projected
> --
> 2.46.0.267.gbb9c16bd4f
>
