Rename fields in State to be more descriptive and add more detailed docs.

[andriyDev]

It can be difficult to understand the difference between the various Box<Behavior<A>> fields in State. I've renamed them to be more descriptive by switching most (but not all) from tuple structs to named structs.

[Sollimann]

Great initiative! Looks good to me when scanning through the code. Can I get a second pair of eyes form you @kaphula before approving to make sure I didn't miss anything?

[kaphula]

I think it looks good. No harm from more descriptive names and documentation. Thanks!

I had intentions to do the most simple use case for each behavior on their documentation entries with doc tests at some point, but only ever finished the WhileAll. I think having similar tests for other behaviors would be nice so you could instantly get a quick idea how a behavior can be used in practice without the need of studying the examples if possible. If you want to work on these as well, I'd be glad to have them, if that is ok with @Sollimann.

[Sollimann]

@kaphula yes, I am happy with that as well. I think that could be a separate PR. Approving this one.

Feel free to squash and commit the changes @andriyDev , let me know if you don't have permission

[Sollimann]

Approved!

TL;DR
I understand where you're coming from, and I appreciate the effort. Returning an Option feels like the most appropriate and lightweight solution for now. It avoids overcomplicating the api and keeps the door open for refactoring later if the need arises.

To your points:

1.) I think we disagree on the semantics here, which is fine. From my point of view ticking a finished tree is not inherently erroneous — it's an unsupported action, but not a failure of execution or logic. The only two possible states here are "tree produces a status" (some value) or "tree is finished" (none). If we ever encounter additional cases where we need more meaningful differentiation down the line, we can always refactor to introduce a more expressive type at that point. However, at the moment, Option is the simplest and most idiomatic fit for the problem we're solving (from my pov).

2.) I agree with this

3.) I also agree that thiserror are one of the more common and stable libs. I want to avoid dependency bloat which is common for so many libs out there. As the code evolves, if we encounter scenarios that truly require advanced error handling, we can reevaluate and introduce a proper error-handling strategy (including dependencies) then

[andriyDev]

@Sollimann I think you may have approved/replied to the wrong PR haha

[Sollimann]

Ups, don't know how I managed to do that haha @andriyDev