C++ Logo

std-proposals

Advanced search

Re: [std-proposals] [[unevaluated]]

From: Jonathan Grant <jgrantonline_at_[hidden]>
Date: Wed, 20 May 2026 23:54:46 +0100
On 20/05/2026 07:46, David Brown via Std-Proposals wrote:
>
> On 20/05/2026 01:16, Thiago Macieira via Std-Proposals wrote:
>> On Tuesday, 19 May 2026 12:58:24 Pacific Daylight Time Ville Voutilainen via
>> Std-Proposals wrote:
>>> In case this idea had actual convincing motivation, there's no reason
>>> *whatsoever* to do it with an attribute.
>>
>> Actually, an attribute might be appropriate here and simply let the compiler
>> warn if the function is actually called in code, instead of making it a hard
>> error. It would not be the end of the world if helper functions that are
>> usually used to compute a type more easily than a sequence of
>> std::conditional_t got actually called.
>>
>> Most of the time, such functions are private in some form or another, so only
>> the author of the code in question is even going to call them. The author can
>> already do a static_assert on a type-dependent false like std::declval does,
>> but will they bother to write that code?
>>
>>
>
> gcc has attributes [[gnu::error("This function must not be called")]] and [[gnu::warning("Calling this gives a warning")]]. The warning or error messages are not emitted if the call is eliminated (via dead-code elimination, only using it in unevaluated contexts, etc.).
>
> These should be reasonable candidates for standardisation?

There is [[deprecated]] which emits a diagnostic warning at the moment.
Although I used attribute error so far for my compile_assert() proposal. Probably [[deprecated]] is more user friendly.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4021r2.pdf

Jonathan

>
> Then the OP can have:
>
> #define unevaluated error("Unevaluated contexts only")
>
> or whatever suits his preferences.
>

Received on 2026-05-20 22:54:50