Yield closures about lang-team

[nikomatsakis]

Discussed in the rust-lang meeting.

There is some amount of excitement and enthusiasm for taking this approach eventually, however we feel like we don't presently have the design bandwidth to oversee a project of this kind, so we're going to put this into final comment period with disposition close.

We do expect at some point in the future to be talking about the ability to have built-in syntax for iterators or streams, and it would make sense to revisit this discussion at that time.

To that end, one thing that would really be appreciated is if someone wanted to try and capture the state of the design discussion here, including unknowns and challenges. We could put it under the lang-team.rust-lang.org website "design notes" section.

[samsartor]

Sounds good! Thanks for hearing me out.

one thing that would really be appreciated is if someone wanted to try and capture the state of the design discussion here

I'll go ahead and put something comprehensive together in the next week when I have some free time.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[programmerjake]

I have a concern that changing the closure argument variables after each yield is very unintuitive (action at a distance) and resume arguments should instead be retrieved from the yield expression like so:

let my_generator = |arg1: i64| {
    // can get initial resume arg by instead starting
    // with something like (syntax up for bikeshedding):
    // |arg1: i64| initial_resume: &'static str = yield {
    //
    dbg!(&arg1);
    let yielded1 = 123;
    // key part of concern:
    // yields yielded1 to caller, gets resume_arg back,
    // does *NOT* modify arg1 since arg1 wasn't mentioned
    let resume_arg: &'static str = yield yielded1;
    dbg!(&arg1); // always prints same thing as previous dbg!
    123.45f64
};
// exact generator type up for debate
let _: Fn(i64) -> (FnPin(&'static str) -> YieldOrReturn<i32, f64>) = my_generator;

[samsartor]

@programmerjake I get it. I was in the yield-expression camp for a long time too. But trust me, assign-on-yield really is the better option! I'll list a few reasons here but if anyone is unconvinced, they should drop by Zulip and duke it out with me there.

1. yield is more like return than like anything else. In fact, under this proposal the only difference between the two is where the closure resumes: after the statement or at the beginning. return reassigns arguments so yield does too.

2. No action at a distance! People are afraid of the "magic mutation" but Rust as a language is really good at dealing with unexpected mutation. Imagine some code:

|items| {
    for _ in items {
        yield;
    }
}

This will error out with something like:

error[E0506]: cannot pass new `items` because it is borrowed
 --> src/lib.rs:3:9
  |
2 |     for _ in &items {
  |              ------
  |              |
  |              borrow of `items` occurs here
  |              borrow later used here
3 |         yield;
  |         ^^^^^ assignment to borrowed `items` occurs here
  |
  = help: consider moving `items` into a new binding before borrowing

So even if a user totally misunderstands the behavior of yield, their data still can't change out from under them.

3. Assign-on-yield handles the common case far better and is almost always more ergonomic. In my prototyping, it is rare that I want to save a resume argument from reassignment and use it later. Take a look at my examples above! In all of them there are only two places where I choose not to discard the previous resume argument: let mut min_health = my_health; and let most = c.to_digit(16);. And even in those places, a yield expression gets in the way more than anything else. let most = (yield None).to_digit(16) isn't great but the only way I can get the AI example to work at all is by pointlessly re-inventing assign-on-yield:

|mut is_opponent_near, mut my_health| loop {
    // Find opponent
    while !is_opponent_near {
        let state = yield Wander;
        is_opponent_near = state.0;
        my_health = state.1;
    }

    // Do battle!
    let mut min_health = my_health;
    ...

[nikomatsakis]

Placing in final comment period and we'll revisit next triage meeting.

[Mark-Simulacrum]

#52 is up.

[joshtriplett]

Closing this issue. People should review #52 asynchronously, and we can talk about it for a future roadmap item.