More flexible SystemInput

[ecoskey]

Objective

Allow functions accepting StaticSystemInput as input to be used as systems accepting the inner type.

Solution

• Add FromInput trait mirroring IntoResult

Testing

• Compiles
• Added test to input.rs

---

Showcase

Click to view showcase

    #[test]
    fn compatible_input() {
        fn takes_usize(In(a): In<usize>) -> usize {
            a
        }

        fn takes_static_usize(StaticSystemInput(In(b)): StaticSystemInput<In<usize>>) -> usize {
            b
        }

        assert_is_system::<In<usize>, usize, _>(takes_usize);
        // test if StaticSystemInput is compatible with its inner type
        assert_is_system::<In<usize>, usize, _>(takes_static_usize);
    }

[ecoskey]

Note that #21916 and cBournhonesque#4 are alternative approaches to the same goal. I'm approving because this is a solid implementation of this approach, but I personally prefer #21916 because the change is smaller, and because associated types are less likely to cause type inference failures.

Valid! I still think I like this approach since it's a bit more symmetrical and doesn't add a new associated type, but I agree there could be problems with inference. I don't think there will be much more than present though, since IntoResult already leads to some ambiguities (like with run_system_cached) and in those cases the types are almost always specified, like you said.

[ecoskey]

Note for final review: This PR is an alternative to #21916, so if you feel that one's better please merge that one instead! 🙂