1 Revision History

1.1 R2

1. Change the name of the paper to reflect more accurately that no type erasure happens (in contrast to the earliest versions of this parper).
2. Updated standard references to the CD; track naming changes.
3. Provide html, because markdown isn’t rendered automatically.

1.2 R1

1. In the changes for views::take and views::drop, also consider constructors of the input type that take iterator and sentinel as arguments (instead of just a constructor that takes a subrange over the two). This enables us to act on such types that don’t provide the range-constructor (e.g. unclear for basic_string_view, in general single-argument constructors are unpopular…). If both constructors are available we prefer the (iterator, sentinel)-constructor to avoid unnecessarily instantiating the subrange-template.
2. We have added such an (iterator, sentinel)-constructor to ranges::empty view so that it becomes one of the types that benefit from the changes to views::take and views::drop.

These changes were approved by LEWG as part of the discussion of R0 in Cologne.

1.3 R0

First revision.

2 Introduction

The current draft standard introduces many range adaptor objects [24.7]. Upon invocation, most of these return a type that is specified together with the adaptor, e.g. views::take returns a specialization of ranges::take_view. Chaining multiple adaptors thus leads to an increasingly nested type. This proposal suggests avoiding nested return types when the input is a view that already represents a “subrange” and it suffices to “change the bounds”.

3 Motivation and Scope

Given the following example:

vector vec{1, 2, 3, 4, 5};
span s{vec.data(), 5};
auto v = s | views::drop(1) | views::take(10)
           | views::drop(1) | views::take(10);

The type of v will be something similar to

ranges::take_view<ranges::drop_view<ranges::take_view<ranges::drop_view<span<int, dynamic_extent> > > > >

Although in fact it could just be span<int, dynamic_extent>, i.e. the same as the original type of s. This is also true for other input types that are “subrange-y” and it would feel natural to preserve the original type if only the size of the “subrange” is changed, i.e. s | views::drop(1) | views::take(3) should be equivalent to s.subspan(1, 3) if s is a span.

We propose that views::drop and views::take return a range of the same type as the input type (and not return a nested type) if the input is a forwarding-range that can be constructed from its own (adjusted) iterator and sentinel (or a ranges::subrange over the iterator-sentinel-pair). This includes:

• a span of dynamic extent (proposed by P1394)
• a basic_string_view (proposed by P1391)
• a ranges::subrange that models ranges::RandomAccessRange and ranges::SizedRange
• a ranges::empty_view (proposed in this paper)

We also propose that the views::counted range factory return a span of dynamic extent (instead of ranges::subrange) if the iterator passed to it models ContiguousIterator.

The proposed changes will strongly reduce the amount of template instantiation in situations where views::drop and views::take are applied repeatedly. They increase the integration of the view machinery from ranges with the views created in the standard independently (span and basic_string_view). And they improve the teachability and learnability of views in general, because some of the simplest view operations now return simpler types and behave as the already documented member functions.

4 Impact on the Standard

This proposal includes changes to the current draft standard. All proposed changes are library changes and none of the proposed changes affect the published international standard.

The proposal targets C++20, because applying these changes afterwards would be breaking.

The currently proposed wording changes depend on the following proposals:

• P1391 Range constructor for std::string_view
• P1394 Range constructor for std::span

Although the wording could be adapted to handle the mentioned types specifically – if the respective papers are not accepted (in time).

P1664 defines concepts that this proposal could use to specify its behaviour more elegantly. It generalises the notion of reconstructible-ranges and makes more ranges “reconstructible” that can then benefit from the optimisations/fixes described here.

5 Design Decisions

5.1 Possible objections to this proposal

Following this proposal means that it will not hold any longer that “the expression views::take(E, F) is expression-equivalent to take_­view{E, F}”, i.e. the adaptor has behaviour that is distinct from the associated view class template. This may be a source of confusion, however by design of the current view machinery users are expected to interact with “the view” almost exclusively through the adaptor/factory object. And this is not the first proposal to define such specialised behaviour of an adaptor depending on its input: P1252 (accepted) modified views::reverse to “undo” the previous reversal when passed a type that already is a specialisation of ranges::reverse_view (instead of “applying” it a second time). The added flexibility of the adaptor approach should be seen as a feature.

While specialisations of e.g. ranges::take_view provide a base() member function that allows accessing the underlying range, this is not true for span or the other return types that we are proposing. However, since the underlying range is of the same type as the returned range, we see little value in re-transforming the range to its original type. It should also be noted that this “feature” (a base() member function) is provided only by some of the views in the draft standard and is not a part of the general view design. It cannot be relied on in generic contexts and combinations with other views and no parts of the standard currently make use of it.

5.2 Stronger proposals

This proposal originally included also changing views::all to type-erase basic_string constants to basic_string_view; all forwarding, contiguous ranges to span; and all forwarding, sized, random-access ranges to ranges::subrange. views::all is the “entry-point” for all non-views in a series of view operations and normally wraps non-view-ranges in ranges::ref_view. Changing views::all in this manner would have a type-erasing effect, e.g. s | views::drop(1) | views::take(3) would return a span, independent of whether s is a span, a vector or an array.

This form of type erasure would preserve all range concepts currently defined. It is, however, possible that future more refined concepts would no longer be modelled by an input type erased in the above fashion. For this reason Casey Carter argued against changing views::all and it was dropped from this proposal.

[The current proposal does not suffer from this uncertainty, because we are preserving the exact input type and there is no erasure.]

6 Technical Specifications

6.1 Changes to views::counted (§24.7.12):

 The name views::counted denotes a customization point object. Let E and F be expressions, and let T be decay_­t<decltype((E))>. Then the expression views::counted(E, F) is expression-equivalent to:
  - If T models Iterator and decltype((F)) models ConvertibleTo<iter_­difference_­t<T>>,
+   - span{addressof(*E), static_­cast<iter_­difference_­t<T>>(F)} if T models ContiguousIterator.
    - subrange{E, E + static_­cast<iter_­difference_­t<T>>(F)} if T models RandomAccessIterator.
    - Otherwise, subrange{counted_­iterator{E, F}, default_­sentinel}.
  - Otherwise, views::counted(E, F) is ill-formed. [ Note: This case can result in substitution failure when views::counted(E, F) appears in the immediate context of a template instantiation. — end note]

6.2 Changes to views::take (§24.7.6.4):

 The name views::take denotes a range adaptor object.
- For some subexpressions E and F, the expression views::take(E, F) is expression-equivalent to take_­view{E, F}.
+ Let E and F be expressions, and let T be remove_cvref_t<decltype((E))>.
+ Then the expression views::take(E, F) is expression-equivalent to:
+ - T{ranges::begin(E), ranges::begin(E) + min<iter_­difference_­t<iterator_t<decltype((E))>>>(ranges::size(E), F)} if that is well-formed and T models forwarding-range.
+ - T{ranges::subrange{ranges::begin(E), ranges::begin(E) + min<iter_­difference_­t<iterator_t<decltype((E))>>>(ranges::size(E), F)}} if that is well-formed and T models forwarding-range.
+ - ranges::take_­view{E, F} if that is well-formed.
+ - Otherwise views::take(E, F) is ill-formed.

These wording changes depend on P1391 & P1394 – however the range constructors are no longer required, because we look for (iterator, sentinel)-constructors, too.

6.3 Changes to views::drop (§24.7.8.3):

 The name views::drop denotes a range adaptor object.
- For some subexpressions E and F, the expression views::drop(E, F) is expression-equivalent to drop_­view{E, F}.
+ Let E and F be expressions, and let T be remove_cvref_t<decltype((E))>.
+ Then, the expression views::drop(E, F) is expression-equivalent to:
+ - T{ranges::begin(E) + min<iter_­difference_­t<iterator_t<decltype((E))>>>(ranges::size(E), F), ranges::end(E)} if that is well-formed and T models forwarding-range.
+ - T{ranges::subrange{ranges::begin(E) + min<iter_­difference_­t<iterator_t<decltype((E))>>>(ranges::size(E), F), ranges::end(E)}} if that is well-formed and T models forwarding-range.
+ - ranges::drop_­view{E, F} if that is well-formed.
+ - Otherwise views::drop(E, F) is ill-formed.

These wording changes depend on P1391 & P1394 – however the range constructors are no longer required, because we look for (iterator, sentinel)-constructors, too.

6.4 Changes to empty_view (§24.6.1):

The following changes make ranges::empty_view a type that gets special treatment from views::take and views::drop.

In §24.6.1.2:

namespace std::ranges {
  template<class T>
    requires is_object_v<T>
  class empty_view : public view_interface<empty_view<T>> {
  public:

+    constexpr empty_view() noexcept = default;
+    constexpr empty_view(T* first, T* last) noexcept;

    static constexpr T* begin() noexcept { return nullptr; }
    static constexpr T* end() noexcept { return nullptr; }
    static constexpr T* data() noexcept { return nullptr; }
    static constexpr ptrdiff_t size() noexcept { return 0; }
    static constexpr bool empty() noexcept { return true; }

    friend constexpr T* begin(empty_view) noexcept { return nullptr; }
    friend constexpr T* end(empty_view) noexcept { return nullptr; }
  };
}

And add §24.6.1.3:

+24.6.1.3 Constructors [range.empty.cons]
+
+empty_view(T* first, T* last) noexcept;
+
+1 Expects: first == nullptr and last == nullptr.
+
+2 Effects: none.

7 Acknowledgements

Thanks to Casey Carter, Eric Niebler, Barry Revzin and Corentin Jabot for feedback on the proposal. Many thanks to JeanHeyd Meneide for alerting me to and involving me in P1664 which would solve some of the things described here more elegantly (and more generically).

8 References

• P1252 Input range adaptors
• P1035 Ranges Design Cleanup
• P1391 Range constructor for std::string_view
• P1394 Range constructor for std::span
• P1664 Reconstructible Ranges