The way I see it, any other solution that is not achieving guaranteed nrvo extensions without any additional markings (this includes functions) is a waste of time.

What you need is quite simple.
Any named variable X that is returned should guarantee nrvo unless a return statement exist that does not return X and X is alive.

I'm perfectly confident that the solution is this, and that this is implementable.
Everything else is just adds clutter to the language and is an automatic no from my part.


If there are any markings to be added, these would be in terms of attributes that have no effect on the generated code, but mark expectations on behavior (like [[fallthrough]], or [[maybe_unused]]):
i.e. you can mark a return statement as [[rvo]] (or something), but that only serves to issue a compiler warning in case the return statement cannot actually achieve rvo, either or not a variable is rvo is not dependent on the attribute.


-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Frederick Virchanza Gotham via Std-Proposals
Sent: Thursday, July 11, 2024 16:32
To: std-proposals_at_[hidden]
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_gmail.com>
Subject: Re: [std-proposals] Stop gap required for NRVO until Anton's paper is assimilated

On Thu, Jul 11, 2024 at 3:28 PM Brian Bi wrote:
>
> As far as I'm concerned, P2025 is dead unless I see evidence to the
> contrary. Future proposals should simply discuss it and then move on.


What do you reckon about having 'factory' and 'after_factory' instead of P2025? It would mean that the core language stays intact, and we just have two new library functions.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]p.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals