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);
    }

[chescock]

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.

For example, world.run_system_cached_with(|_: StaticSystemInput<In<usize>>| {}, 0) would fail with "type annotations needed" under this PR, since I can be either In<usize> or StaticSystemInput<In<usize>>, while under #21916 it would unambiguously be In<usize>.

I don't know of any realistic use cases that would run into that problem, though. The only reason to use StaticSystemInput is if you're generic in the input type, like pipe, and in that case the types will all be written out anyway.

[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.

[ItsDoot]

As long as we can't prove further type inference issues in general usecases, I'd be fine with this actually. Looks good besides the one thing.

[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! 🙂

[alice-i-cecile]

Can you and @chescock please summarize how this relates to / contrasts to #21917 for me please? I want to make sure I understand the context before merging either.

Edit: ah, I see that's occurred above. I'll chew on this.