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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk