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.
-- >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
