Combine `State` and `NextState`

[lewiszlw]

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

System may need receive two params to process one state (a bit redundant and counterintuitive). Is it possible that combining State and NextState into one?

[hymm]

here's some discussion from the Stageless RFC about this

maniwani on Aug 23, 2022
We initially had a consolidated resource, but anecdotally some users said they liked how iyes_loopless has them split.

The split just has the advantage that one system can queue a transition without blocking another system that just wants to read the current state.

Member
@maniwani maniwani on Aug 24, 2022 •
Oh, the more important property with split resources is that CurrentState isn't marked as changed when you queue a transition. (#2343)

Member
Author
@alice-i-cecile alice-i-cecile on Aug 24, 2022
The change detection argument is very compelling to me.

Member
@cart cart on Aug 25, 2022
Hmmm ok yeah theres serious value in being able to detect state changes. Can we change it to State instead of CurrentState for some additional terseness? I think "current" is implied.

Alternatively, we could just use interior mutability for State::set_next(). Given that state transitions will happen approximately once per frame, the overhead (even if we use a mutex) won't matter at all.

@alice-i-cecile alice-i-cecile on Aug 25, 2022
I like the rename. I don't love the interior mutability though because it breaks change detection for NextState.

Less essential, but likely still useful.

[lewiszlw]

Hmmm, make sense. What about Query-like feature to combine resources?

[alice-i-cecile]

The SystemParam derive macro works nicely for that :)

I'm leaning towards "this won't actually be an improvement" because of the change detection argument, so are you okay to close this out?

[lewiszlw]

OK, I'll look at how SystemParam works.