Create a `When` system param wrapper for skipping systems that fail validation

[alice-i-cecile]

I really like the optional system param thing, I was wondering about that myself.

I'm less sold on having a single skipping wrapper; however if we did decide to go with it my vote would be to call it When<T> (eg. When<Res<MyResource>> or When<Single<Window>> or When<Populated<MyComponent>>) to indicate that this system runs when the parameter is valid.

Just having a few separate wrappers with this functionality built in seems fine. Having a dedicated When<T> wrapper does increase flexibility somewhat... There are situations where users may want their app to panic if they don't have exactly one entity with a single value, I think I've had situations where I'd have liked to enforce that invariant before.

---

Just so we are all on the same page, your proposed semantics would basically be:

1. Every system parameter errors by default when invalid.
2. The Option<T> wrapper turns an error into a successful None parameter.
3. The When<T> wrapper skips the system when it encounters an error.
4. The fallback error handler lets users further customize how unwrapped errors are handled.

I don't hate that. One slightly awkward result is the behavior of Option<When<T>> and When<Option<T>>. Should the former skip?

Originally posted by @NthTensor in #18504 (comment)

[chescock]

We may also want a Result<T, ???> param that's like Option but lets you distinguish Skipped from Invalid.

---

One use case I had in mind for generic Option parameters is the safe PipeSystem example.

The issue there is that regular PipeSystem will only validate the parameters to the first system, since the first system might change whether the second system should run. But the example uses ParamSet, which currently validates all sub-parameters.

I wanted to be able to write that using ParamSet<A::Param, Option<B::Param>> so that the ParamSet only validates the first parameter, and then the pipe system can bail out early if the second parameter is None.

... but Option isn't quite enough, since we want to return an error on Invalid but success on Skipped. So I think we'll eventually want a Result wrapper to support higher-order systems.

[homebrewmellow]

Single, Option, Populated already have that behavior, no? it says so:
"Those parameters will prevent systems from running if their requirements aren’t met."

[NthTensor]

Single, Option, Populated already have that behavior, no?

This proposal would change the semantics so that they error (see point 1) unless combined with a When<T> wrapper.

[alice-i-cecile]

The Option<Single> behavior doesn't seem particularly intuitive or useful to me. I opted not to change it, but I would prefer a consistent blanket implementation.

[NthTensor]

Agreed

[tbillington]

So When<Res<T>> would be kind of equivalent to sys_fn.run_if(resource_exists::<T>) ?

[chescock]

I think the intention of the original behavior of Option<Single> is a case where an entity may or may not exist, but should never have duplicates. Like, you might have a "current target" or not, but you never have two. I think that's more common then a case where you might have any number, but want to run special code when there is exactly one.

Although then the ideal behavior for Single might be 0 => Skip, 1 => Valid, N => Invalid.

(I do prefer having a blanket Option impl! But I believe the original behavior of Option<Single> was actually useful in practice.)

[NthTensor]

I'm fine with any of this but, for the record, I don't think we should be shipping any other changes to this system in 0.16 now that Alice has basically fixed it.