Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🐞 [Bug]: method that requires state, but does not switch_to, returns stateless object. #36

Closed
jkneer opened this issue Nov 27, 2024 · 2 comments · Fixed by #38
Closed
Assignees
Labels
bug Something isn't working

Comments

@jkneer
Copy link
Contributor

jkneer commented Nov 27, 2024

What happened?

#[type_state(
    states = (Unset, FullyConfigured),
    slots = (Unset)
)]
struct BobTheBuilder {}

#[impl_state]
impl BobTheBuilder {
  #[require(Unset)]
  #[switch_to(FullyConfigured)]
  pub fn init() -> BobTheBuilder {
    BobTheBuilder {}
  }
}

  #[require(FullyConfigured)]
  pub fn dosth(self, Option<u32>) -> BobTheBuilder {
    BobTheBuilder {}
  }

In this case the call to dosth() will return a stateless BobTheBuilder.
This is unexpected, because this basically switches the state from FullyConfigured to stateless without a switch_to statement. On the other hand this can be fixed by adding a switch_to macro to the initial state.
So this implementation

  #[require(FullyConfigured)]
  #[switch_to(FullyConfigured)]
  pub fn dosth(self, Option<u32>) -> BobTheBuilder {
    BobTheBuilder {}
  }

works as expected.

Expected behavior

This behaviour took me by surprise. I would have expected that the OutputState = InputState as long as I do not call switch_to and that I would not need to add switch_to as long as I just want to require a state and update the struct, but do not want to change the state. The current behaviour is kind of the inverse of what I expected by intuition.

@jkneer jkneer added the bug Something isn't working label Nov 27, 2024
@ozgunozerk
Copy link
Owner

You are absolutely right, if switch_to is not specified, it should not preserve the type.

Will deal with this soon, thanks for the report 💯

@ozgunozerk
Copy link
Owner

This one is resolved, will issue a new release after #35 is also resolved

@ozgunozerk ozgunozerk self-assigned this Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants