P3060 R1 Add std::views::upto(n)

[wg21bot]

P3060R0 Add std::ranges::upto(n) (Weile Wei)

[wg21bot]

P3060R1 Add std::views::upto(n) (Weile Wei, Zhihao Yuan)

[dhollman]

SG9 agreed on the following summary of the discussion in the room, with the understanding that it would be posted to GitHub as the outcome of the discussion.

---

SG9 believes that the failure of the following (already arcane because of the name iota) beginner code to compile is a defect in the standard that is worth our time to address

vector v = { /*...*/ };
for (auto i : views::iota(0, ranges::size(v))) {
  // ...
}

Most of the rest of the discussion revolved around the name upto, the most popular alternative to which was indices. The arguments on each side were as follows:

• upto
  • Arguments in favor
    • proposed in the paper
    • analogous to std::upper_bound
    • concise
    • some people think this is unambiguous and obvious
    • upto sounds like iota (we can teach that "four letter things that start and end with vowels generate integers")
      • Nico says this isn't a joke
      • The more crazy something is to remember, the better you remember
  • Arguments against:
    • Ruby uses upto to be inclusive
    • Kotlin uses to to be inclusive
    • Sounds like views::take particularly in the context of a pipeline
    • Others feel this is ambiguous
      • moreso than upper_bound because the latter is clearly a math term
    • upper_bound isn't a perfect precedent because uniform_int_distribution is inclusive of it's upper bound, so there's no complete uniformity in the language.
    • Teachers in the room didn't like it
    • upto is ambiguous with up_to
    • difficult to search
• indices
  • Arguments in favor
    • precedent and usage experience in range-v3
    • it's a noun, which makes sense because it's a generator
    • Python (in numpy) uses indices to mean this
      • enumerate references Python already
    • We have somewhat analogous precedent in std::index_sequence
    • Some people think this is unambiguous
      • Including people who teach C++ for a living
  • Arguments against
    • The analogous precedent in std::index_sequence could be confusing because index_sequence is always size_t
    • Sounds like it should be the indices of an object
      • but we could later add indices_of to help disambiguate
    • Other people find this not obvious
    • Non-native English speakers may not know that indices is the plural of index

---

We took the following polls to summarize the outcomes of our discussion:

_Change the name views::upto to views::indices (with the understanding that we anticipate probably later adding a facility like views::indices_of)_

SF	F	N	A	SA
6	6	2	3	0

Result: Consensus for change (borderline strong) Attendance: 17 Authors: N and A Author Against: the name doesn't look as generic as upto, but it's acceptable

SG9 believes that we should use the is-integer-like exposition-only constraint rather than the std::integral (is-integer-like allows implementation-defined types and removes bool).

SF	F	N	A	SA
6	9	0	0	0

Result: Unanimous Consent Attendance: 17 Authors: SF (x2)

Forward P3060R1 to LEWG with the two changes polled above for inclusion in C++26.

SF	F	N	A	SA
11	4	2	0	0

Result: Strong consensus Attendance: 17 Authors: SF

---

SG9 also polled on the inclusion of a facility like indices_of in the current paper, in an attempt to make the case for indices as a more compelling name. The poll had weak consensus, but one attendee discovered a late argument (raised in their strongly against statement) that convinced the room that indices_of should be in a separate paper: For a sized_range, indices_of has to choose whether to return a range of size_type or difference_type, either of which may lead to implicit conversions or other incompatibilities. The former choice may not work with indexing into the range, but the latter may be inconsistent with views::indices(ranges::size(r)), which would use the size_type. We anticipate a separate paper proposing this facility.