> > But at the very least, I know that there's no way to use SFINAE to see
> whether an implementation has a specific library header. Would there be
> value in enabling people to write code that will adapt at that level to
> implementations that have made different degrees of progress toward
> implementing standard library features?
>
> We have some implementation experience here: Clang provides a
> __has_include, but nothing more granular.

Hmm, this raises an interesting question.

The lexical grammar has a production called "header-name". Its purpose is to prevent macro-expansion. That's important for header names within angle brackets. Otherwise, imagine what might happen if someone tried to include <errno.h> more than once, considering that <errno.h> defines a macro named "errno".

The interesting thing about this __has_include macro is that it is presumably a new context in which a header-name token is expected. That makes it pretty special.

Not that it isn't already pretty special. It certainly can't be implemented as a macro, not if its job is to scan include directories.

The ideal outcome of what we're doing would be a nearly seamless transition from one standard to the next; that it would be possible to write code that just works on a bunch of implementations, regardless of their degree of support for new features.

But there's probably no way to achieve that as regards new library headers. If a compiler doesn't have support for header-testing, code that tries to test for a new header is likely just to fail to compile, even if it could gracefully and correctly recover from the absence.

Clark