On Thu, 4 Apr 2024 at 18:37, Aaron Ballman <aaron_at_[hidden]> wrote:
> Okay, that leaves some really interesting situations then.
>
> Should #include <stdbit.h> compile because it's not mentioned at all
> by the C++ standard and so it's basically a user-provided header?

Depends on whether your system has such a header and the inclusion of it
compiles. C++ doesn't guarantee the answer to be "yes" on either part.

> Should use of strdup from <string.h> compile despite not being in C17,
> because it is in POSIX?

On a non-POSIX system, there's no guarantee that it will, but it
might, for various
implementation-defined reasons.

> Should use of __STDC_VERSION_LIMITS_H__ from <limits.h> not compile
> because it wasn't in C17 nor in POSIX?

Maybe, for implementation-defined reasons.

> I don't see how users are served by anything other than providing the
> interfaces from the header they included. I don't think it's
> defensible from an implementation perspective to say "we will only
> give you some C standard interfaces in C++ mode, based on which C
> standard the C++ library was based on at the time" -- that is just
> inexplicable to anyone but a committee member and seems like a burden
> on implementers because that also means C11 interfaces can't be
> exposed in C++14 or C++11 mode, etc.

Despite being a member of both committees, as a user, the C++23
standard tells me that
the portable C standard library in C++23 is C17. That shouldn't pull
lowercase macro
names from the future. It may pull in such lowercase macros for
implementation-defined
reasons, but as a user, I will not exactly appreciate a vendor
springing such a trap on me.

> Also, I can't square how that fits with "The intended use of these
> headers is for interoperability only. It is possible that C++ source
> files need to include one of these headers in order to be valid ISO C.
> Source files that are not intended to also be valid ISO C should not
> use any of the C headers."
>
> If it's for interoperability with valid ISO C... C23 is valid ISO C
> whether WG21 has rebased or not.

The C++23 standard specifically refers to C17. That's what it's
interoperable with. It doesn't try to make promises
it can't realistically keep, including a promise that it's
interoperable with whichever future C standard. It explicitly
does not promise the latter, for good reasons.

> > Why, for heaven's sake, is 'unreachable' a macro in C? That is instant
> > trouble for C++,
> > where every user expects to be able to scope names via namespaces.
>
> I'm not interested in rehashing decisions that are already too late
> for either committee to change, just trying to figure out how to move
> forward within the world we have.

I wasn't asking to rehash a decision, I was asking for rationale.