`std::flat_set` dispatches non-c++17 iterators to container's `insert(const_iterator, InputIterator, InputIterator)`

[hewillk]

#include <flat_set>
#include <iterator>
#include <sstream>
#include <ranges>
#include <boost/interprocess/containers/vector.hpp>
 
int main() {
  boost::container::vector<int> v;
  std::flat_set s(v);
  std::istringstream ints("0 1 1 0");
  auto r = std::ranges::subrange(std::istream_iterator<int>(ints),
                                 std::istream_iterator<int>())
         | std::views::transform([](int i) { return i * i; });
  s.insert_range(r);
}

https://godbolt.org/z/6P3rnod76

[frederick-vs-ja]

See the comments in this function:

llvm-project/libcxx/include/__flat_set/utils.h

Lines 57 to 71 in 56f5bcb

	template <class _Set, class _Range>
	_LIBCPP_HIDE_FROM_ABI static void __append(_Set& __set, _Range&& __rng) {
	if constexpr (requires { __set.__keys_.insert_range(__set.__keys_.end(), std::forward<_Range>(__rng)); }) {
	// C++23 Sequence Container should have insert_range member function
	// Note that not all Sequence Containers provide append_range.
	__set.__keys_.insert_range(__set.__keys_.end(), std::forward<_Range>(__rng));
	} else if constexpr (ranges::common_range<_Range>) {
	__set.__keys_.insert(__set.__keys_.end(), ranges::begin(__rng), ranges::end(__rng));
	} else {
	for (auto&& __x : __rng) {
	__set.__keys_.insert(__set.__keys_.end(), std::forward<decltype(__x)>(__x));
	}
	}
	}
	};

Can we just resolve this issue as invalid Resolved as invalid, i.e. not a bug because boost::container::vector<int> doesn't provide insert_range and hence doesn't meet the C++23 sequence container requirements ([sequence.reqmts])?

Or should we submit an LWG issue to make some new member functions optional for sequence containers?

CC @huixie90.

[huixie90]

I can simply add a cpp17 iterator check on the second branch. I am be conflicted about this. On the one hand, we can simply say that boost container is not standard compliant. On the other hand, even the boost one is not standard compliant, how can users’ ones be better?

[ldionne]

I think it would be important to file a LWG issue about this. Sure, we can fix this as an extension, but at the end of the day the Standard has to be unambiguous about what containers should be supported in flat_foo.

[ldionne]

^ Per discussion just now, I don't think a LWG issue is actually necessary.

[frederick-vs-ja]

Ah I've submitted LWG4261. Theoretically, use of queue, priority_queue, and stack with old custom sequence containers can be broken in C++23, which is possibly undesired.