Boost.Config actually uses the feature testing macros when available and when applicable (in combination with other things, i.e. an understanding of what the C++ implementation in question actually is known to support, regardless of what it advertises). Using the feature testing macros alone may not be what you want. I'd be happy to used Boost.Config - that's where I looked first. But I don't see what I need in there.
Pull requests are welcome.
Indeed, or file a feature request.
Note that historically Boost.Config has never added new macros unless
there is demand from within Boost.
And while it's true that we have been laggardly in adding C++17 feature
macros, so far no one has ever asked for them either... not once till now.
BTW, what I'm missing from this discussion, is exactly what C++17
features you are actually interested in?
Finally, with regard to the CD6 macros, one of their issues, is that to
determine if std lib feature X is present in header Y, then you must
first include header Y. That means that were Boost.Config to wrap SD6
feature detection in it's own convenience macros, then it would end up
#including the entire std lib - I think we can all agree that that's not
a viable option. So if you want to know if is_invocable is present in