Re: is_constant_evaluated

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-08-05 08:09:51

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.