Sweep the codebase for components out-of-spec to the C++20 WP

[CaseyCarter]

Anything not integrated by now is likely not important enough to be integrated.

[ericniebler]

Yes please. I'm particular, I'm blocked by the not-too-spec way you define value_type.

[CaseyCarter]

I'm particular, I'm blocked by the not-too-spec way you define value_type.

Fixed in bb1655783d9573f880d4b62f2cd302bef4ae2d81.

[cjdb]

Should functions like find_if_not retain their __f wrapper?

template <class I, class S, class Pred, class Proj = identity> // need to swap Pred and Proj
requires
	InputIterator<__f<I>>() &&
	Sentinel<__f<S>, __f<I>>() &&
	IndirectPredicate<Pred, projected<__f<I>, Proj>>()
__f<I> find_if_not(I&& first, S&& last, Pred pred, Proj proj = Proj{})
{
	return __stl2::find_if(__stl2::forward<I>(first), __stl2::forward<S>(last),
		__stl2::not_fn(__stl2::ref(pred)), __stl2::ref(proj));
}

find_if_not in N4622 doesn't mention decay_t, but I can't project what will happen if it's removed.

[CaseyCarter]

It should be safe to unwrap those and take the function arguments by value. Any resulting ambiguities are extensions that I need to move to namespace ext.