On Mon, Feb 9, 2026 at 8:09 AM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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.
>
I think this direction would be a hard sell to EWG because it adds a new
user-facing syntactic construct, many uses of which would cause UB (like
you said, it can be detected most of the time, but that might not be good
enough---some folks will want wording to guarantee it's ill-formed). This
contrasts with the P2025 approach, where the user-facing complexity is low,
using it incorrectly simply causes either an extra move or a compilation
error (in case the return type is immovable), and the bulk of the
complexity is on the specification and implementation side.

If we had to add a new syntactic construct, an alternative that I think is
worth considering is an epilogue that can be present only on a definition
and, similar to a postcondition assertion, can have a result binding. The
epilogue would be guaranteed to be evaluated exactly once on the callee
side, immediately before postcondition assertions are evaluated (or,
immediately before when the postcondition assertions would be evaluated if
any were present). The epilogue would be able to, uhh, lock the mutex or
whatever (I am not convinced that this is a useful application) using the
result binding. The main advantage of this over the "explicit return slot"
approach is that it doesn't introduce any new UB: if you managed to get
there without actually constructing the return value, then your program
already had UB before you added the epilogue.

>
>
> -----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 don't think they are. In particular, I don't think P2025 was especially
complex wording-wise. However, the feedback that the author received
regarding the implementation issues would've been overwhelming to pretty
much any first-time WG21 proposal author. But I don't think it amounted to
"this approach is too complex to implement". The committee just wanted
Anton to do the work to resolve those issues, and my guess is that he just
didn't have the time or the motivation or the implementation expertise or
perhaps all three.

>
>
> > > 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*