On Wed, Jan 29, 2025, 9:35 AM Peter Bindels via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Wed, Jan 29, 2025 at 3:55 PM Karl Semich via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> 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.
>>
>
> This to me reads like a great argumentation to put into a paper, that can
> be submitted for inclusion into C++26 or 29. If we have a
> known-bug-inducing current setup, that is not used much, that we can then
> still fix and have working in C++26/29, it would make sense to write a
> paper & to see if it can be seen at Austria - or shortly after. Teaching
> everybody "generator is kinda broken and you need to define this wrapper
> function" seems counterproductive, when we can propose to change
> "suspend_always" to "suspend_never" in one location and fix it for
> everybody.
>

That changes the behavior of generator. Specifically, when do things
actually get executed:

auto f() -> generator<int> {
    println("hi");
    co_yield 1;
}

Does this print when you call f() right away, or does it print when you
start iterating over f()? Python, Rust, and Kotlin, for instance, say the
latter. I haven't exactly done an exhaustive survey here, but I don't know
right now of any existing practice for the former.

Barry

>