This doesn't look acceptable to me, but what to do? The only solution I can see is to simply not support these features in Boost.Config, but rather rely on users needing these features checking the std detection macros directly. Which will work up until someone implements a feature without defining the appropriate macro :(
Thoughts? You could just define the macro based on compiler version. That could be backed by a test which not only checks for __cpp_lib_integer_sequence but for std::integer_sequence itself. Compiler version is irrelevant, it's the std lib that matters. I think for most std lib's, yes we could use existing machinery to check this, I'm not sure about clang/libc++ though - _LIBCPP_VERSION appears to be stuck at 1101 and the clang version number is notoriously unreliable. Any clang experts confirm this? PS: I thought it was enough to include any STL header (e.g. cstddef) to get all these macros defined. Isn't it the case? How would one test for a feature that is implemented in a new header? Please see the paper linked to, but basically it suggests using __has_include(<name>). Of course technically, none of this is in the standard, rather it's contained in an ever changing "standing document".
John.