Describe the bug

TL; DR: IIUC VSO-1308657 points to a bug of MSVC STL, not of the compiler.

The operator() of ranges::iter_move's type (std::ranges::_Iter_move::_Cpo) currently uses deduced return type:

Such strategy unexpectedly interacts with projected, as:

• many ranges algorithms check concepts for projected<I, Proj>, and then
• these concepts eventually (via indirectly-readable-impl) check the result type of ranges::iter_move on projected<I, Proj>, however,
• when ranges::iter_move uses deduced return type, the body of its operator() needs to be instantiated, and hence projected::operator* also needs to be instantiated.

According to the Standard wording, projected::operator* is not defined, and thus such instantiation renders the program ill-formed, no diagnostic required. The known issue VSO-1308657 "Standard Library Header Units: std::projected::operator*() error LNK2019: unresolved external symbol" seems because of this.

MSVC STL adds the function body to projected::operator* as a workaround, which is arguably conforming under the IFNDR umbrella. But such extraneous instantiations seem undesired.

Command-line test case

Not reproducible because STL has the aforementioned workaround.

However, when I attempt to diagnose misuse of projected::operator* by adding static_assert(false); (as implementation of a potential LWG issue; already mailed to LWG Chair -> is LWG-4270 now), the undesired error can be raised from every use of ranges::equal (and many other ranges algorithms).

Expected behavior

No undesired instantiation happens. Call to projected::operator* can be rejected at compile time.

STL version

Every existing version since #565 (which implemented projected).

Additional context

Other implementations have already switched not to use deduced return type for ranges::iter_move:

• LLVM-D120417 (llvm/llvm-project@fbcd523)
• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92894 (https://gcc.gnu.org/cgit/gcc/commit/?id=6fedf28c7921f125be75a9f688a7b845a1b5663b)

Other related PRs:

• Ranges <range> machinery #82 (added ranges::iter_move)
• <format> Properly handle multibyte encodings in format strings #1815 (added the workaround to projected::operator*)
• chunk_by_view's helper lambda returns bool #2890 (removed the non-workaround code)