Date: Wed, 29 Jan 2025 15:55:03 +0100
Thanks, that wrapper solution is just the thing!
I didn't find a way that move semantics would help with the argument case; the temporaries still go out of scope before data can be moved in (unless one uses a wrapper function, a patch, or writes their own generator).
Given when a wrapper function is not used that the misbehavior is (a) severe, (b) undocumented, and (c) not reported by compilers and implementations, my personal opinion is still that this is a bug.
The standard should clearly state that passing temporaries to a generator or defining temporary generators is illegal or at least undefined.
However, if generators executed eagerly, it would prevent a wide class of these memory corruption errors.
Move semantics may help address when generators themselves are defined as temporaries.
Karl Semich
> Date: Wed, 29 Jan 2025 07:13:49 +0000
> From: Tiago Freire <tmiguelf_at_[hidden]>
> To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
> Subject: Re: [std-proposals] std::generator initial_suspend dropping
> all temporaries out of scope
> Message-ID:
> <AS2P194MB218727CA4B6A074DE6908636C2EE2_at_[hidden]>
>
> Content-Type: text/plain; charset="utf-8"
>
> Wouldn?t this problem be better solved with move semantics?
>
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of L?n?rd Szolnoki via Std-Proposals
> Sent: Wednesday, January 29, 2025 7:38 AM
> To: std-proposals_at_[hidden]
> Cc: L?n?rd Szolnoki <cpp_at_[hidden]>
> Subject: Re: [std-proposals] std::generator initial_suspend dropping all temporaries out of scope
>
> You can have a wrapper function (not coroutine) that returns std::generator.
>
> std::generator<T> wrapper(ReferenceType x) {
> return [](ValueType x)->std::generator<T>{
> /*implement coroutine*/
> }(DeepCopy(x));
> }
>
> DeepCopy(x) is evaluated before the initial suspend and its result lives on the coroutine frame.
>
> On 28 January 2025 18:43:20 GMT, Karl Semich via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
> Hi!
>
> I'm trying out c++23 std::generator and noticing that I cannot safely pass arguments to my generators that are temporaries such as std::initializer_list. It seems like this is because promise_type's initial_suspend returns suspend_always, so passed temporaries are out of scope as soon as initial code is executed.
>
> Where can I read about this and best practices, or is it a mistake? It looks like a mistake to me.
>
> My understanding is that if initial_suspend returned suspend_never, then the developer could accept temporaries and copy their contents to the stack in the initial code block of the generator. But as it is, there can be surprising subtle memory access errors in code not aware of the limitation that generators cannot safely accept temporaries at all.
>
> Ideally there would be some way to configure this.
>
> Karl Semich
> -------------- next part --------------
> HTML attachment scrubbed and removed
>
> ------------------------------
>
> Subject: Digest Footer
>
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> ------------------------------
>
> End of Std-Proposals Digest, Vol 70, Issue 69
> *********************************************
>
I didn't find a way that move semantics would help with the argument case; the temporaries still go out of scope before data can be moved in (unless one uses a wrapper function, a patch, or writes their own generator).
Given when a wrapper function is not used that the misbehavior is (a) severe, (b) undocumented, and (c) not reported by compilers and implementations, my personal opinion is still that this is a bug.
The standard should clearly state that passing temporaries to a generator or defining temporary generators is illegal or at least undefined.
However, if generators executed eagerly, it would prevent a wide class of these memory corruption errors.
Move semantics may help address when generators themselves are defined as temporaries.
Karl Semich
> Date: Wed, 29 Jan 2025 07:13:49 +0000
> From: Tiago Freire <tmiguelf_at_[hidden]>
> To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
> Subject: Re: [std-proposals] std::generator initial_suspend dropping
> all temporaries out of scope
> Message-ID:
> <AS2P194MB218727CA4B6A074DE6908636C2EE2_at_[hidden]>
>
> Content-Type: text/plain; charset="utf-8"
>
> Wouldn?t this problem be better solved with move semantics?
>
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of L?n?rd Szolnoki via Std-Proposals
> Sent: Wednesday, January 29, 2025 7:38 AM
> To: std-proposals_at_[hidden]
> Cc: L?n?rd Szolnoki <cpp_at_[hidden]>
> Subject: Re: [std-proposals] std::generator initial_suspend dropping all temporaries out of scope
>
> You can have a wrapper function (not coroutine) that returns std::generator.
>
> std::generator<T> wrapper(ReferenceType x) {
> return [](ValueType x)->std::generator<T>{
> /*implement coroutine*/
> }(DeepCopy(x));
> }
>
> DeepCopy(x) is evaluated before the initial suspend and its result lives on the coroutine frame.
>
> On 28 January 2025 18:43:20 GMT, Karl Semich via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
> Hi!
>
> I'm trying out c++23 std::generator and noticing that I cannot safely pass arguments to my generators that are temporaries such as std::initializer_list. It seems like this is because promise_type's initial_suspend returns suspend_always, so passed temporaries are out of scope as soon as initial code is executed.
>
> Where can I read about this and best practices, or is it a mistake? It looks like a mistake to me.
>
> My understanding is that if initial_suspend returned suspend_never, then the developer could accept temporaries and copy their contents to the stack in the initial code block of the generator. But as it is, there can be surprising subtle memory access errors in code not aware of the limitation that generators cannot safely accept temporaries at all.
>
> Ideally there would be some way to configure this.
>
> Karl Semich
> -------------- next part --------------
> HTML attachment scrubbed and removed
>
> ------------------------------
>
> Subject: Digest Footer
>
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> ------------------------------
>
> End of Std-Proposals Digest, Vol 70, Issue 69
> *********************************************
>
Received on 2025-01-29 14:55:09