Consider these two approaches that can represent an \"optional int\":
using std_optional_int = std::optional;
using my_optional_int =
The optimization is technically permitted, even with std::is_trivially_copyable_v being false. However, it may require an unreasonable degree of "cleverness" for the compiler to find. Also, for the specific case of using std::optional as the return type of a function, the optimization may need to be done at link-time rather than compile-time.
Performing this optimization would have no effect on any (well-defined) program's observable behavior,* and is therefore implicitly allowed under the as-if rule. However, for reasons which are explained in other answers, the compiler has not been explicitly made aware of that fact and would need to infer it from scratch. Behavioral static analysis is inherently difficult, so the compiler may not be able to prove that this optimization is safe under all circumstances.
Assuming the compiler can find this optimization, it would then need to alter this function's calling convention (i.e. change how the function returns a given value), which normally needs to be done at link time because the calling convention affects all of the call sites. Alternatively, the compiler could inline the function entirely, which may or may not be possible to do at compile time. These steps would not be necessary with a trivially-copyable object, so in this sense the standard does inhibit and complicate the optimization.
std::is_trivially_copyable_v ought to be true. If it were true, it would be much easier for compilers to discover and perform this optimization. So, to answer your question:
Is this a QoI issue, or is there something in
std::optional's specification preventing this optimization?
It's both. The spec makes the optimization substantially harder to find, and the implementation is not "smart" enough to find it under those constraints.
* Assuming you haven't done something really weird, like #define int something_else.