On 8/5/21 4:18 AM, Gavin Lambert via Boost wrote:
On 5/08/2021 12:53 pm, Andrey Semashev wrote:
On 8/5/21 2:14 AM, Gavin Lambert wrote:
On 5/08/2021 7:03 am, Andrey Semashev wrote:
I might add that including <type_traits> just to test got a feature macro is not good.
It wouldn't be good in something like Boost.Config, no.
But if you're doing that check at actual point of use then you've almost certainly already included <type_traits> anyway, so it's "free".
No, not really. Not only because needing is_constant_evaluated does not equate to needing type traits or metaprogramming, but because if the macro check says "no" then you've included <type_traits> for nothing.
Yes, really. That's the header in which std::is_constant_evaluated is defined (as well as the feature macro you're wanting to check), so if you're wanting to use it then you have to include the header anyway.
There's not really any point in making the include itself conditional (even if you could), except perhaps on something more generic (such as "is C++11 or later", to detect cases when the header wouldn't exist).
The point is reducing compile times. When all you need from <type_traits> is is_constant_evaluated, it is wasteful to include the header, especially if that component doesn't exist. The feature macro being defined there is a standard library design bug as it forces you to buy a car before a test drive. It was fixed by <version>, which luckily is available when is_constant_evaluated was introduced. Other feature macros were introduced before that header and their use is problematic unless you force the C++20 minimum bar. Anyway, I still think it is worth to have boost::is_constant_evaluated.