P3136 R0 Retiring niebloids

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 looked through the std::ranges namespace and found only two function templates that currently are neither niebloids nor CPOs. These are:

std::ranges::to (which would need universal template parameters)
std::ranges::get which needs to participate in ADL (for a number of reasons)

This paper does not affect anything outside of namespace std::ranges. After the change, everything else in std::ranges (except for the two above function templates) would be customization point objects (but not necessarily customizable---this is a known shortcoming of the terminology today, and outside the scope of this paper).

We audited std::ranges and existing implementations thereof and we do not believe there will be any observable changes from this paper (because existing implementations).

The following example that does not work on any compiler is the worst thing that we could come up with as a room that would theoretically change if any compilers were conforming:

#include <algorithm>
#include <ranges>
#include <vector>

int main()
{
  using std::sort;
  using std::ranges::sort;
  std::vector<int> vec{1, 3, 2};
  sort(vec);
}

(This is a result of a defect in the wording; this is technically allowed now, but shouldn't be because we intended for function objects to be a valid implementation of niebloids.)

SG9 took the following polls after the discussion summarized above:

Given this information, SG9 forwards P3136R0 to LEWG for inclusion in C++26

SF	F	N	A	SA
8	3	0	0	0

Conclusion: Unanimous Author: SF Attendance: 12

Given the state of existing practice, SG9 recommends applying P3136R0 as a defect report for C++20.

Unanimous consent

cplusplus / papers

P3136 R0 Retiring niebloids #1790