On Mon, 2 Jun 2025 at 12:44, Robin Savonen Söderholm via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> There is also the possibilities of using type-information for this:
>
> template</*arithmetic*/ T>
> struct strictly_positive { T value; ...}
>
> ...
>
> auto res = sqrt(strictly_positive{my_value});
>
> But in all fairness, I think that the case of an optimization for a keyword addition is 'weak'; we should let the compiler or possibly LTO 'erase' branches that can be deduced unused in a function. Maybe having an attribute to 'guide' the compiler optimization could be potentially useful but:
> 1. it will only work when the definitions of a function is fully known inside a translation unit (so practically inline-d or static)

That's not correct. The whole point of a declaration-level
optimization annotation is to be able to optimize the calling code
without needing to see
the definition. There are other attributes that do that, like [[gnu::pure]].

You don't need this facility to optimize the definition, because you
can just add an [[assume]] into it.

> 2. it will probably invoke UB if it is violated

Yep.

> 3. you would need to prove (show code for example) that you really can get better performance at times when the compiler itself can't do the optimization on its own.

The compiler can't optimize based on the definition code if it doesn't
see it, and LTO is not used everywhere. Such examples already exist
for
things like [[gnu::pure]].

Whether all that makes this a good idea is a very different question.
It might be a rather good idea to tie the facility into an
implementation-defined
configuration mechanism like how contracts are tied to one, so that
the assumptions can be turned off, or turned into asserts, or turned
into assert+assume
combinations.