C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Named Return Value Optimisation [[nrvo]]

From: Jan Schultke <janschultke_at_[hidden]>
Date: Tue, 10 Feb 2026 12:23:46 +0100
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.

On Sun, 8 Feb 2026 at 01:54, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> For a few years now people have been talking about bringing guaranteed
> NRVO into C++ so that we can return an immovable-and-uncopiable type
> by value from a function after having altered the variable, for
> example:
>
> mutex Func(void)
> {
> mutex m;
> m.lock();
> return m;
> }
>
> Sebastian and I were writing a paper ( https://wg21.link/p3357 ) which
> would lend to code such as:
>
> mutex Func(void)
> {
> return prvalue<mutex>( [](mutex &m){ m.lock(); } );
> }
>
> There's also a very long paper by Anton: https://wg21.link/p2025
>
> To achieve NRVO in C++, I think we need a happy medium between three
> things:
> (1) Good enough functionality and convenience for programmers
> (2) Not too much hassle for compiler writers
> (3) Not too much complication for standards writers
>
> I think the happy medium is to mark the return slot as follows:
>
> mutex Func(void)
> {
> [[nrvo]] mutex m;
> m.lock();
> return m;
> }
>
> and to only allow one variable marked 'nrvo' in any scope. So the
> following is disallowed:
>
> mutex Func(void)
> {
> [[nrvo]] mutex m2;
> [[nrvo]] mutex m;
> m.lock();
> return m;
> }
>
> but the following is allowed:
>
> mutex Func(void)
> {
> {
> [[nrvo]] mutex m;
> m.lock();
> }
>
> [[nrvo]] mutex m;
> m.lock();
> return m;
> }
>
> Furthermore, if there is an 'nrvo' variable in scope, then the return
> statement must return said variable, so the following is disallowed:
>
> mutex Func(void)
> {
> [[nrvo]] mutex m;
> m.lock();
> mutex m2;
> return m2;
> }
>
> I've written this into the GNU g++ compiler, you can test it here:
>
> https://godbolt.org/z/5oe34M731
>
> In the above GodBolt you need to use [[gnu::nrvo]] instead of [[nrvo]]
> but I'll fix that on Monday.
>
> Here's the compiler patch:
>
> https://github.com/healytpk/gcc-thomas-healy/commit/tag_nrvo
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2026-02-10 11:24:04