In the test files, replace the old-style tests with a simple static_assert, matching the current style as depicted in e.g. ranges_uninitialized_default_construct.pass.cpp.
Preserve is_function_like (but renamed to is_niebloid) at @ldionne's request. The removal of this test helper will happen in D116570 if at all.
@ldionne wrote:
(1) It's physically possible to land the libcxx/test/ changes without the libcxx/include/ changes. Shall I do that? (and then leave this PR open for discussion of the libcxx/include/ changes)
(2) Re Hyrum's Law: You have to keep in mind that "there's no such thing as an archetype." C++ has only leaky abstractions. Here we have to choose, for each niebloid in the library, should it be copyable or non-copyable? final or non-final? default-initializable or non-default-initializable? We cannot avoid choosing one or the other. Whichever one we choose, the user might (accidentally or on purpose) end up relying on it. They'll have some template that does one thing if the type is copyable and a different thing if it's not, and then boom, technically we can't change that without an ABI break.
The paper standard saves us here by making most of those problematic things IFNDR, so we actually can change this stuff without worrying about the breakage to users. Therefore I think our goal should be simplicity and predictability: we should do the simplest thing that works, because complexity without reason is bad.
FWIW, today, GCC accepts and MSVC rejects https://godbolt.org/z/hhae7zEf9
Everyone (including libc++) accepts things like
These are all IFNDR as far as I'm aware: the user is supposed to know that std::ranges::next (despite being a niebloid) isn't supposed to be used in these ways. This is basically analogous to the stuff that appears in SD-8: "sure you can try doing this, but the library vendor doesn't have to coddle you and you're on your own if it breaks later."