Rather than having concepts, we should move these tests into a `.verify.cpp` file. requires-expressions fail silently, so we don't get signal here on why something like `HasIotaIter<InputIteratorNotInputOrOutputIterator>` is false: only that it is. In a verification test file, we can use Clang to inspect the diagnostic and confirm that `std::ranges::iota(std::forward<Iter>(iter), std::forward<Sent>(sent), std::forward<Value>(val))` fails for the intended reason reason.

Matter of style, but I'd personally prefer this to look like: ```suggestion return operator()(ranges::begin(__r), ranges::end(__r), std::move(__value)); ``` up to you.

Same question as above, reason for the names in the parameters?

Is there a reason you added names to these parameters?

I think this might be a merge thing, this should probably go after `fold_left_with_iter_result` on new line 68.

These tests seem good, but in a future PR it might be nice to centralize testing for all `_result` types (see also previous thought about centralizing the `_result` types' definitions). No change requested.

It is not standard practice here to re-export the `*_result` types in the modules that use them; see, for example, `std_private_algorithm_ranges_for_each` not re-exporting `in_fun_result`.

nit: this should go below `in_value_result`, as it is later in both the standard and is alphabetically later.

I would personally prefer if these template type parameters were named `template <class _Out, class _Value>` or something along those lines (with the parameters below named `<class _Out2, class _Value2>`); no change requested, feel free to ignore.

This accidentally doubles `contains` from a merge conflict; also, instead of adding a new line, you should edit line 10 instead.

We need to test both in `constexpr` mode and at runtime, so this should be: ``` test_results(); static_assert(test_results()); ``` It's a pattern we follow in general -- it's always possible for code to have different behavior between the two modes, whether due to `if consteval`, compiler bugs, etc.

I'm missing something. I thought the non-const assignment should _not_ be selected, but `expected` values being different from the original implies that it is?

Can we also test in constexpr mode (`static_assert(test_results());`) -- `test_results` would have to be `constexpr` and `return true`?

Nit: please include `<utility>`.

Nit: please sort the includes alphabetically.

Please use `std::weakly_incrementable` and `std::incrementable`. You'll also need to support `void operator++(int)` for when a type is weakly incremenetable, but not incrementable.

Please move this conditional logic into a separate test case.

Please avoid using logic in test cases.

Similar to the `__iota` namespace, this is likely going to be removed. Please track the discussion in #76542.

This namespace isn't necessary, and I'm working on a patch to remove the ones that are already checked in. Since this patch is happening concurrently, would you mind removing this namespace here? Alternatively, you can track #76543 and hold off removing this until that lands in main.

I'd also like to see a test with a non-fundamental type, and especially one that behaves differently when it's `const` to test the `std::as_const` in the loop.

```suggestion assert(result.value == starting_value + N); ``` I think this should be equivalent.

These test don't need to be inside a function. You can just put them at global scope. Otherwise they look really nice.

The formatting changes in here are nice, but would be better handled in a separate PR, just to make it clear what actually changed.

Please also add a note in `libcxx/docs/Status/Cxx23.rst` which states what parts are currently implemented.

Please also update `libcxx/docs/RangesAlgorithms.csv`.

Newline!

Newline!

Unrelated: Please update the `robust_against_*` tests.

```suggestion #include <__utility/move.h> ```