[Feature Request] Using owned Input and State

[kyp44]

This crate is great and I'd love to use it, but it seems like its design limits the ability to have the states store data that can be used to calculate outputs. In particular it seems that the only way to get data into the state machine at all is to include it as part of the Input type, for example having Input be an enum type where the variants have data. However, StateMachine::consume only takes an immutable reference to Input so it's basically impossible to move data from the Input to the State without copying it. Similarly, because StateMachineImpl::transition gets an immutable reference to the Input and the State, it's again not possible to move data from one state to another and/or from the Input without copying.

I realize that this would be a breaking change, but to me it makes more sense to always use owned version of Input instead of immutable references since the user could just use an immutable reference itself as Input if that's what they wanted to do. The State issue is tricky on account of the fact that StateMachineImpl::transition may or may not need to make a new State from the old one. Again, it would be nice to be able to move data from the old state to the new one in this case, but I'm not sure how that could be handled since, if the state is not transitioning, the old State needs to be retained and therefore cannot be moved into transition.

It may be that this crate is really just intended to be used for data-less state machines so I'm trying to do something it was not really intended to do. This is fine since I can always use the Typestate pattern.

[eugene-babichenko]

Just moving Input definitely makes sense. Moving State is possible if we assume that there are on illegal (Input, State) pairs and no change in state is represented just by transition(Input::A, State::B) = State::B.

[nsengupta]

I am a level 3 noob in Rust, but having implemented Production ready - and used - FSMs in other languages ('C' using table-driven implementations and function pointers) and Scala/Java (Akka FSMs), I am quite keen to make use of similar concepts in Rust. While searching, I have come across this crate. It is compact and easy.

I am staring at the same problem as this ticket elaborates. I feel that some mechanism should exist where the Output can be modified when a transition happens. This means that I should be able to pass an initialized Outputeither through the Construction function (state machine owns the Output struct), or an Optional output variable to the transition() function (the caller owns the Output struct).

These are two possibilities that come to my mind; there could be more idiomatic usage. Being able to return a updatable Output as a result of transition, helps a lot.

I am not sure if I am making sense. I am keen hear your views.