feature(gen_blocks): cannot use the ? operator in a gen block that returns ()

[kanashimia]

As per gen_blocks RFC:

Even when ? is used within a gen block, the block must return a value of type unit or !. That is, it does not return a value of Some(..), Ok(..), or Continue(..) as other such blocks might.

But currently upon using ? an error occurs: cannot use the ? operator in a gen block that returns ()

To reproduce: https://godbolt.org/z/4fGT9EM8q

[kanashimia]

CC: @oli-obk

[compiler-errors]

This is kind of expected given the desugaring for expr? being something like match expr { Ok(t) => t, Err(e) => return e.into() } (that's not exactly the desugaring, but it illuminates the problem) ,since gen blocks have no return type, just a yield type.

I guess we could make ? aware of the gen block and instead desugar to a return; when it's given an error type that can be converted to () or something... though this is the first time we'd be giving a special meaning to ? based on its context.

[jrandolf]

Making ? aware of generator blocks is a little awkward. Already ? performs an Into call (through the residual work), so adding more functionality may be adding a bit too many eggs in the basket.

The problem with this issue is the semantics of a theoretical '?' in a generator is not necessarily the canonical extension. For example, what is expected if '?' is used in a for block? Should it just return? Or perhaps break/continue? In a non-gen situation, these question don't exist because the function ends at the decision to return.

A solution could be to have a user-crate with a few macros that perform the necessary functionality. For example, it could have "or_yield", "or_yield_continue", and "or_yield_break". Note the "or_yield_break" would accept 1-2 arguments. Names would need to be bikeshed.

[oli-obk]

For example, what is expected if '?' is used in a for block? Should it just return? Or perhaps break/continue? In a non-gen situation, these question don't exist because the function ends at the decision to return.

So would the generator. My expected desugaring of the Err case is

yield Err(e);
return;

Forcing the generator to be Iterator<Item = Result<T, E>>.

If you want the generator to continue yieldig items after an Err, you need to manually yield. This short circuiting behaviour matches what you get from .collect<Result<Vec<T>, E>>() on an iterator of Result<T, E>s

[jrandolf]

The comment was just to express all PoVs. IMO, I'd also lean toward making ? short-circuit. For the most part, it seems the other cases aren't used, however there is a bias here since collect made the choice not to collect errors as well.

But is it the case gen will never implement return values? For example, JavaScript generators allow return values separate from yielded values.

[Kolsky]

It would be surprising if ? didn't short circuit. And there are no examples where ? doing anything else would be useful.

Returning values from generator other than () isn't blocked on this proposal either, since it should be forward-compatible by explicitly requiring return to be of unit type.