`<xutility>`: `default_initializable<move_iterator<It>>` may be problematic for Clang

[frederick-vs-ja]

Describe the bug
TL;DR: LLVM-60293 is likely not a bug and we may need to change move_iterator's default constructor to make Clang happy.

In cases like views::join_with(r1 | views::as_rvalue, r2 | views::as_rvalue) (already occur in test file due to #3359), the iterator type of the resulted join_with_view wraps an move_iterator and default_initializable<move_iterator<It>> is detected, where It is the iterator type of r1. When It is a non-default-initializable input_iterator type (more precisely, when It{} is ill-formed), MSVC STL's implementation of move_iteratorresults in weird behavior of Clang.

MSVC STL's move_iterator has a defaulted default constructor:

STL/stl/inc/xutility

Line 3942 in f8b8ad6

_CONSTEXPR17 move_iterator() = default;

And the required value-initialization is performed via default member initializer:

STL/stl/inc/xutility

Line 4165 in f8b8ad6

iterator_type _Current{};

Per [class.default.ctor]/2.3, the default member initializer makes the default constructor of move_iterator never deleted (which is decided in CWG-927). Given a non-default-initializable It, default_initializable<move_iterator<It>> ask whether is_constructible_v<move_iterator<It>> is true, which may make the program ill-formed per this note, and implementation divergence seems (unfortunately) permitted (discussed in llvm/llvm-project#60293).

There're many iterator-related facilities using default_initializable to constrain their default constructors. We may need to change move_iterator's default constructor to make them usable with move_iterator and non-default-initializable input iterators when compiling with Clang.

The current approach has some benefits:

• the exception specification is automatically strengthened;
• the default constructor can be sometimes implicitly constexpr in C++14 mode, although this makes little sense because most operations are only constexpr since C++17.

Possible resolutions (may be only applied for Clang):

• Just making the default constructor non-defaulted. Cons:
  • either we need a non-conforming constexpr in C++14 mode, or we'll break some non-portable constexpr uses of move_iterator in C++14;
  • exception specification strengthening may be preferable, but throughput might be (sightly) damaged.
• Adding base classes to make the default constructor conditionally deleted and otherwise defaulted. Cons:
  • also damages throughput;
  • the adapted iterator may be designed in such way that asking whether it satisfies is_default_constructible is ill-formed, while neither input_iterator nor Cpp17InputIterator cares default-initializability.

[StephanTLavavej]

@CaseyCarter notes that many occurrences are affected, not just move_iterator. We talked about this at the weekly maintainer meeting and we want to wait until the Clang issue has a definitive resolution (either fixed or by design) before proceeding here. (We probably don't need to use temporary workarounds until the Clang fix ships, because this hasn't been encountered during normal usage, only during development of <ranges>.) Personally, I am willing to accept throughput costs here, so I don't think that should affect whatever course of action we choose.

[frederick-vs-ja]

LWG-4125 touches this.