[libc++] `<ranges>`: `ranges::to` use range-based for loops in append branches

[hewillk]

llvm-project/libcxx/include/__ranges/to.h

Lines 112 to 124 in 6c062af

	for (auto&& __ref : __range) {
	using _Ref = decltype(__ref);
	if constexpr (requires { __result.emplace_back(std::declval<_Ref>()); }) {
	__result.emplace_back(std::forward<_Ref>(__ref));
	} else if constexpr (requires { __result.push_back(std::declval<_Ref>()); }) {
	__result.push_back(std::forward<_Ref>(__ref));
	} else if constexpr (requires { __result.emplace(__result.end(), std::declval<_Ref>()); }) {
	__result.emplace(__result.end(), std::forward<_Ref>(__ref));
	} else {
	static_assert(requires { __result.insert(__result.end(), std::declval<_Ref>()); });
	__result.insert(__result.end(), std::forward<_Ref>(__ref));
	}
	}

Range-based for loop is not guaranteed to be well-formed for input_range as it does not extract iterator-pair through ranges::begin/ranges::end:

https://godbolt.org/z/Kc3dsvnfW

#include <ranges>

struct Vector {
  void push_back(int);
};

struct OnlyADLRange {
  void begin() = delete;
  void end() = delete;
  friend int* begin(OnlyADLRange&);
  friend int* end(OnlyADLRange&);
};

int main() {
  std::ranges::contiguous_range auto r = OnlyADLRange{};
  auto v = r | std::ranges::to<Vector>(); // only well-formed in libstdc++
}

[hewillk]

range_formatter have similar issues:

llvm-project/libcxx/include/__format/range_formatter.h

Lines 197 to 201 in 4228a6e

	for (auto&& __e : __range) {
	if (__use_separator)
	__ctx.advance_to(ranges::copy(__separator_, __ctx.out()).out);
	else
	__use_separator = true;

[hewillk]

It looks like libc++ extensively uses range-for loops to iterate over ranges when implementing P1206, so this should be something that can be modified uniformly (if worth it).

[frederick-vs-ja]

I think I can fix these issues (if wanted). But they mean that we can't traverse a range using range-for in generic code, which sounds weird.

[philnik777]

Yeah, I think there should be an LWG or CWG issue about this. Not being able to iterate a range with a range-based for loop sounds a lot like a design flaw to me.