`yield` without value from a `gen` block

[Jules-Bertholet]

I tried this code:

// edition 2024
#![feature(gen_blocks)]
fn foo() -> impl Iterator {
    gen {
        yield;
    }
}

I expected to see this happen: The gen blocks RFC does not specify the behavior of bare yield (without an argument). There are three possible choices, each with good reasons for and against:

• Reject it entirely
• Return None from Iterator::next()
• Equivalent to yield ()

Instead, this happened: The current behavior is that of yield ().

Meta

rustc --version:

1.79.0-nightly (2024-04-06 aa1c45908df252a5b0c1)

cc #117078

@rustbot label F-gen_blocks

[compiler-errors]

I'm not certain why it would make sense to do anything other than yield (). It seems like a total parallel to return () and I don't think it's particularly beneficial to do anything else.

Given that the iterators returned by gen blocks are fused (#122829), it wouldn't make much sense to yield None either, since that makes yield equivalent to return (quit the block and don't come back).

We could perhaps "reserve" the behavior by making it error, but seems unnecessarily cautious imo.

[Jules-Bertholet]

Arguments for and against each option:

Reject it entirely

Pros:

• Forward compatible with either of the other two options
• Lowest chance of user confusion

Cons:

• Least useful/permissive choice

Return None from next()

Pros:

• Allows directly implementing deliberately unfused iterators with gen, which is otherwise impossible
• Conceptually intuitive: yield /* nothing */ yields nothing, i.e. None

Cons:

• Inconsistent with break and return
• Unfused iterators are rare
  • Though not unknown, I implemented one just today and would have liked to be able to use gen for it
• If used by mistake, the type checker won't catch it

Equivalent to yield ()

Pros:

• Consistent with break and return

Cons:

• Iterators returning () are rare
  • Though also far from non-existent

---

See also discussion on the RFC thread. Personally I lean towards the "return None" option.

[Jules-Bertholet]

Given that the iterators returned by gen blocks are fused

The compiler could detect the presence of a bare yield anywhere in the block, and omit the FusedIterator impl only in that case.

[compiler-errors]

That's a lot of subtlety (and complexity) for a really niche use case, imo, and I think that the user should just use impl Iterator<Item = Option<T>> in that case and explicitly yield None.

[Jules-Bertholet]

At least for my one use-case today that motivated me to open this issue, that would have been an ergonomic hit.

---

The use case: I am consuming an API that give me a stream of data. Sometimes there is new data available, sometimes there isn't yet (but might be in the future). My iterator returns None from next() in the "no new data" case, enabling me to do stuff like this:

loop {
    for new_data in &mut iter {
        process_data(new_data);
    }
    
    do_something_else_for_a_while();
}

The above example could be easily converted to use impl Iterator<Item = Option<T>> and while let Some(Some(new_data)) = iter.next() instead. However, an unfused iterator also lets me do the following, which is not so simply adapted:

let mut all_the_data = vec![];
loop {
    all_the_data.extend(&mut iter);
    do_something_else_for_a_while();
}

[oli-obk]

I think code that tries to be clever should be explicit. And using an unfused iterator to only collect up to the first None seems very clever to me.

The behavior was not specified in the RFC, because it seemed obvious to me that we want to be consistent with break and return. I'll amend the RFC.

I'm closing this issue as I don't see T-lang accepting

• diverging from break and return
• implicit behaviour that is possibly a footgun
• for a niche use case that is already supported and could be simplified with a fuse like adaptor.

[Jules-Bertholet]

I think code that tries to be clever should be explicit. And using an unfused iterator to only collect up to the first None seems very clever to me.

Out of curiosity, what would be your preferred "non-clever" version? An iterator over Options combined with take_while()?

[oli-obk]

A function that explicitly turns an unfused iterator into an iterator of iterators so you can just write two nested for loops.