[ 2025-10-21; Reflector poll. ]

Set priority to 4 after reflector poll.

"Does it matter in practice? If the type is unspecified, it's fine for misuse to be non-portable."

"Would like a diagnostic, don't care about SFINAE. Not clear to me that the current `setfill` wording disallows the mixed-character-type case at all ..."

"NAD, not been a problem for a quarter of a century."

Currently, it is unspecified whether any of operator<< or operator>> for the "unspecified" return type of an I/O manipulating function is SFINAE-friendly.

There's implementation divergence. E.g. the following program is consistently rejected by implementations although the standard doesn't strictly require it to be ill-formed. Among the implementations, libstdc++ and libc++ make the failure SFINAE-friendly, while MSVC STL doesn't (demo):

#include <iostream>
#include <iomanip>

int main() 
{
  std::cout << std::setfill(L'*');
}

It seems better to eliminate such implementation divergence. Perhaps it's also better to require them to be SFINAE-friendly to reduce potential conflicts with user-provided operators.

If it's intended to allow implementation divergence, perhaps we should clarify the intent.