Section 6.1 of P1739R4 changes the specification of views::take as follows:
-2- The name views::take denotes a range adaptor object ([range.adaptor.object]).
Given subexpressions E and F, the expression views::take(E, F) is expression-equivalent to take_view{E, F}.Let E and F be expressions, let T be remove_cvref_t<decltype((E))>, and let D be range_difference_t<decltype((E))>. If decltype((F)) does not model convertible_to<D>, views::take(E, F) is ill-formed. Otherwise, the expression views::take(E, F) is expression-equivalent to:
— if T is a specialization of ranges::empty_view ([range.empty.view]), then ((void) F, decay-copy(E));
— otherwise, if T models random_access_range and sized_range and is
— a specialization of span ([views.span]) where T::extent == dynamic_extent,
— a specialization of basic_string_view ([string.view]),
— a specialization of ranges::iota_view ([range.iota.view]), or
— a specialization of ranges::subrange ([range.subrange]),
then T{ranges::begin(E), ranges::begin(E) + min<D>(ranges::size(E), F)}, except that E is evaluated only once;
— otherwise, ranges::take_view{E, F}.
Consider the case when T = subrange<counted_iterator<int>, default_sentinel_t>. Then according to the above wording, views::take(E, F) is expression-equivalent to
T{ranges::begin(E), ranges:begin(E) + min<D>(ranges::size(E), F)}; (*)
But this expression is ill-formed for the T we chose because subrange<counted_iterator<int>, default_sentinel_t> has no matching constructor that takes an iterator-iterator pair.
More generally the above issue applies anytime T is a specialization of subrange that does not model common_range. But a similar issue also exists when T is a specialization of iota_view whose value type differs from its bound type. In this case yet another issue arises: In order for the expression (*) to be well-formed when T is a specialization of iota_view, we need to be able to construct an iota_view out of an iterator-iterator pair, and for that it seems we need to add another constructor to iota_view.