Alternative to an attribute. The function receives an explicit return parameter. This one represents the storage of the returned type On that storage a class of that or a derived type can be constructed and destructed. Not constructing an object is UB - most cases can be detected. So instead of using a local (automatic/scoped) variable, a special parameter is used, which similar to the explicit this parameter does not appear in parantheses at the call site. The aforementioned way gives the full freedom, but is kind of low-level as the storage is provided.   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 09.02.2026 13:23 Betreff:Re: [std-proposals] Named Return Value Optimisation [[nrvo]] An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Sun, Feb 8, 2026 at 12:06 PM Jens Maurer wrote: > > >    (2) Not too much hassle for compiler writers > >    (3) Not too much complication for standards writers > > Not among the primary goals of a proposal. I think these two are the primary reason why no progress has been made on NRVO in C++. > > I think the happy medium is to mark the return slot as follows: > > > >   mutex Func(void) > >   { > >     [[nrvo]] mutex m; > >     m.lock(); > >     return m; > >   } > > [... rules omitted ...] > > How does this use of an attribute fit the idea that attributes > have optional semantics, given that the program will be ill-formed > without the attribute present? Maybe use there brackets for cannot-be-ignored attributes, e.g. [[[nrvo]]] [[[nouniqueaddress]]] -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals