In my opinion, as an "owning polymorphic function wrapper", managing the internal callable object's lifetime to match that of the wrapper itself is intuitive. This is not a rigid rule, but trying to make it conformable might make the wrapper more user-friendly.



> One possible caveat with the relaxed "stored callable, or a copy of it" guarantee: if that permission applies to all trivially copyable callables, I think it can change fairly ordinary stateful-callable semantics. For example, a mutable lambda capturing an int may be trivially copyable; invoking a fresh copy each time could produce 1, 1, 1 instead of 1, 2, 3.
>
> So I wonder if the intended relaxation should be narrower: only for the empty + trivially default-constructible + trivially copyable case used to justify this optimization, rather than for trivially copyable targets in general.


I think narrower constraints are necessary:
1. empty: Any capturing lambda and non-empty functor may have states;
2. trivially copyable: This ensures there is no side effect in lifetime management;
3. either "having `static operator()`" or "trivially default constructible": This means the wrapper does not need to store the callable object.


If a callable object satisfies all the above constraints, it is mostly stateless. Eliminating the storage of such callables is compliant with the "as-if" rule, with only one exception as far as I know: using `this` (the pointer value itself) to generate state. For example:


```cpp
struct F {
    uintptr_t operator()() {
        return reinterpret_cast<uintptr_t>(this);
    }
};
```


It is technically safe to remove "trivially default constructible" from the 3rd constraint. However, doing so would cause all non-capturing lambdas without the `static` qualifier to miss this stateless optimization, even though they are obviously stateless.


With a simple benchmark, I found that missing this optimization leads to a 27.9% performance decrease on x86_64. It also adds an additional 20 bytes of ROM cost for each lambda on RV32GC. See <https://godbolt.org/z/PchjWExEd>.




Kim J. Smith





On 2026-08-18 08:58:34, "Capita Lai via SG14" <sg14_at_[hidden]> wrote:

Arthur O'Dwyer via SG14 <sg14_at_[hidden]p.org> 於 2026年8月17日週一 下午11:19寫道：

You could "eliminate" it by relaxing the guarantees you document for your wrapper. Instead of documenting that you always call the stored callable, you could document that you call "the stored callable, or a copy of it," and furthermore document that you do not make copies unless the stored callable is trivially copyable (i.e. you guarantee never to make an expensive copy).

One possible caveat with the relaxed “stored callable, or a copy of it” guarantee: if that permission applies to all trivially copyable callables, I think it can change fairly ordinary stateful-callable semantics. For example, a mutable lambda capturing an int may be trivially copyable; invoking a fresh copy each time could produce 1, 1, 1 instead of 1, 2, 3.

So I wonder if the intended relaxation should be narrower: only for the empty + trivially default-constructible + trivially copyable case used to justify this optimization, rather than for trivially copyable targets in general.

I like the underlying idea of making target identity explicitly non-semantic for that category; I just think the scope of that permission may matter.

Capita



本郵件可能包含威旭資訊股份有限公司之機密或個人資料，僅限指定收件人閱讀與使用。如您並非收件者，請立即刪除本郵件，並勿任意使用、傳播或揭露其內容。收件人應自行確認附件與連結安全，並妥善保護郵件內容，善盡資訊安全責任。

This email may contain confidential or personal information of VICI Holdings, and is intended only for the designated recipient. If you are not the intended recipient, please delete this message immediately and refrain from using, disclosing, or distributing its contents. The recipient is responsible for verifying the safety of attachments and links, and for safeguarding the information in accordance with information security policies.