You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I have given this a look and we stand between 2 choices:
Either one has type states which is nice for compile time checking but cumbersome to use in runtime and place in structs,
or we go with the state being an enum in the timer itself which means runtime checking of states and we loose the compile time checks.
One can also wrap the timer object in an enum, where each enum variant maps to a state.
However this would be a bit weird as one turns the state problem inside out with making state explicit to the user to handle.
Eg TimerState::Running(timer), where the user has to check and do the right thing depending on the TimerState.
@korken89 I think the issues brought up with the current type-state scheme are serious enough to switch over to runtime checks. I like the elegance of the type states, but it's just not a good fit for this situation. So I think storing an enum state in the timer is a good way to go.
Ref: #75
The State type parameter means that a Timer that is going to change state cannot be (nicely) stored in a struct.
Does the Type type parameter also block some use cases?
The text was updated successfully, but these errors were encountered: