I think the meaning of [[nrvo]] as discussed in this thread was not just a performance optimization, but to allow modification after construction of non-moveable objects. The [[nrvo]] attribute would guide the compiler, which objects to create in the return slot instead of the local stack space. -> If the objects are moveable they could be moved from the local stack space to the return slot later on. -> But for moveable objects that performance optimization is not optional. And it would not be nice, if the compilation sometimes fails, whenever the compiler chooses to ignore (or does not support) the attribute.   -----Ursprüngliche Nachricht----- Von:Jan Schultke via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 10.02.2026 12:24 Betreff:Re: [std-proposals] Named Return Value Optimisation [[nrvo]] An:std-proposals_at_[hidden]; CC:Jan Schultke <janschultke_at_[hidden]>; A potential stepping stone toward "enforced optimizations" would be attributes that result in a warning when an optimization isn't performed, without altering the semantics of the program. This could be generally applied to a few optimizations: * [[nrvo]] would issue a warning when NRVO is not performed for an object. * [[always_inline]] would issue a warning when a function is not inlined. * [[tail_call]] would issue a warning when a return statement does not result in a tail call. This delegates the question of when NRVO, inlining, tail call optimization, and other such things happen to QoI. An implementation could consider [[always_inline]] a hint to inline even on debug builds because it would otherwise result in poor QoI and a warning. The implementation and wording effort for this is low, compared to hard guarantees.