[libc++] deque::prepend_range rejects some valid code

[philnik777]

struct InPlaceOnly {
  constexpr InPlaceOnly() {}
  InPlaceOnly(const InPlaceOnly&) = delete;
  InPlaceOnly(InPlaceOnly&&) = delete;
  InPlaceOnly& operator=(const InPlaceOnly&) = delete;
  InPlaceOnly& operator=(InPlaceOnly&&) = delete;
};

struct EmplaceConstructible {
  EmplaceConstructible(const EmplaceConstructible&) = delete;
  EmplaceConstructible& operator=(const EmplaceConstructible&) = delete;
  EmplaceConstructible& operator=(EmplaceConstructible&&) = delete;
  EmplaceConstructible(EmplaceConstructible&&) = delete;
  constexpr EmplaceConstructible(const InPlaceOnly&) {}
};

template <template <class...> class Container>
constexpr void test_sequence_prepend_range_emplace_constructible() {
  InPlaceOnly input[5];
  types::for_each(types::cpp20_input_iterator_list<InPlaceOnly*>{}, [&]<class Iter> {
    std::ranges::subrange in(Iter(input), sentinel_wrapper<Iter>(Iter(input + 5)));
    Container<EmplaceConstructible> c;
    c.prepend_range(in);
  });
}

This code is correct, but currently rejected by our deque::prepend_range implementation.

[frederick-vs-ja]

I'm unsure whether this is valid. The code seemingly violated the requirements in [sequence.reqmts]/98, as the T is non-movable EmplaceConstructible for the example. See also LWG3742.

[philnik777]

Huh, I didn't realize prepend_range has different preconditions than append_range. IMO we should still fix this at least for bidirectional iterators as a matter of QoI.