On 17/07/2024 22:07, Tiago Freire wrote:
>> How do I achieve the same thing with P3357, especially with taking care of exception safety?
>
> The short answer is. You don't!
>
> The only thing P3357 cares about is that the object is capable of being modified in some way (besides being affected by its constructor) and maintain rvo, which previously required nrvo to implement (because nrvo is optional). The question of multiple objects potentially being constructed at the same memory address before returning (and delaying the decision of which one can be nrvo) is not even a thing that you can write with P3357.
> And as far as exception safety is concerned, I'm not in the slightest bothered by it given that if an exception is thrown the unwinder must be competent enough to understand the context it has been thrown in and call the appropriate routine to clean it up.

I'm not sure how that would work in general, as that context can be
entirely opaque to the std::factory call itself. It needs to be
specified in what state should the passed in `setup` function should
leave the object if it exits by exception.
>
>
>
> -----Original Message-----
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Lénárd Szolnoki via Std-Proposals
> Sent: Wednesday, July 17, 2024 21:56
> To: std-proposals_at_[hidden]
> Cc: Lénárd Szolnoki <cpp_at_[hidden]>
> Subject: Re: [std-proposals] Stop gap required for NRVO until Anton's paper is assimilated
>
>
>
> On 16/07/2024 09:23, Frederick Virchanza Gotham via Std-Proposals wrote:
>> On Mon, Jul 15, 2024 at 4:33 PM Jason McKesson wrote:
>>>
>>> This is why understanding the philosophy behind something like
>>> guaranteed NRVO is so important. It exposes the issues of going from
>>> lvalue to prvalue back to lvalue and the myriad of complexities
>>> around it. You can't just gloss over it; it must be central to any
>>> such proposal.
>>
>>
>> std::factory is now P3357, available here:
>>
>> https://isocpp.org/files/papers/P3357R0.html
>>
>> In the future we were thinking we would rename 'factory' to
>> 'construct_modify', and rename 'after_factory' to 'invoke_modify'.
>
> In P2025 there is guaranteed copy elision for `w` in the following:
>
> Widget foo(int i) {
> {
> auto w = Widget(i);
> if (w.some_observer()) {
> return w;
> }
> }
> return Widget(0);
> }
>
> The way it works in practice is that `w` gets constructed on the return slot, then depending on the result from the observer it is either returned from there, or it's destroyed and a new object (Widget(0)) is created on the same return slot before returning from the function. The explicit scope for `w` is important here.
>
> Last time I tried I do get NRVO here for clang, but not for gcc.
>
> How do I achieve the same thing with P3357, especially with taking care of exception safety?
>
> Cheers,
> Lénárd
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals