Default piping via system return type

[Aceeri]

What problem does this solve or what need does it fill?

Plenty of time I end up using let Ok(...) else { return; } and such for early returning systems where I just want no-op without the required state I want. This isn't too bad but it bloats the code/makes it harder to read, which is where the ? operator comes in handy. And then we can pipe to ignore. However I think we might be able to go slightly further than this in terms of ease of use.

What solution would you like?

Define 'default pipes' for the return type of a system. For example if I define a system like:

fn plugin(app: &mut App) {
    app.add_systems(Update, my_system);
}

fn my_system(arg1: Option<Res<Arg1>>, mut arg2: Query<&mut MyComponent>)
    -> Result<_, _, ignore> // custom Result with a third generic for "pipe function"
{
    let arg1 = arg1?;
    let arg2 = arg2.get_mut(arg1.entity)?;
    // do stuff
}

This would be the equivalent of:

fn plugin(app: &mut App) {
    app.add_systems(Update, my_system.pipe(ignore));
}

fn my_system(arg1: Option<Res<Arg1>>, mut arg2: Query<&mut MyComponent>) -> Result<_, _> 
{
    let arg1 = arg1?;
    let arg2 = arg2.get_mut(arg1.entity)?;
    // do stuff
}

What alternative(s) have you considered?

Just use the normal piping when we add the system to the world. Or maybe implement a default response for a BevyError? I'm not sure. It might be nice to be able to specify different responses based on the error we returned, e.g. not having this resource is fine, but if the entity doesn't have this component thats an invariant.

[alice-i-cecile]

Right, the idea is to specify the error handling policy in the Result<(), BevyError> type, based on the handling policy specified in the type signature of BevyError (or a custom Result equivalent)?

I really like the core idea: it's clear, terse and keeps the "how are these errors handled" right beside the code that's returning the error.

With respect to:

It might be nice to be able to specify different responses based on the error we returned, e.g. not having this resource is fine, but if the entity doesn't have this component thats an invariant.

This is pretty doable now! We have a lovely .with_severity method, and the default fallback error handler now respects the returned severity.

All the same though, I think that improving the UX of the "please handle all errors from this systems in such-and-such a way" would be quite nice.

[Aceeri]

Right, the idea is to specify the error handling policy in the Result<(), BevyError> type, based on the handling policy specified in the type signature of BevyError (or a custom Result equivalent)?

I really like the core idea: it's clear, terse and keeps the "how are these errors handled" right beside the code that's returning the error.

With respect to:

It might be nice to be able to specify different responses based on the error we returned, e.g. not having this resource is fine, but if the entity doesn't have this component thats an invariant.

This is pretty doable now! We have a lovely .with_severity method, and the default fallback error handler now respects the returned severity.

All the same though, I think that improving the UX of the "please handle all errors from this systems in such-and-such a way" would be quite nice.

Ohhh, I hadn't seen the changes in 0.19 for this. Definitely an improvement there.