Author here - I do get this critique, and of course API design is subjective, but there was a rationale behind the design choices. Putting each policy in its own package allowed the API to be slightly more concise. And having the API use a generic to represent a function's result type allowed different parts of the API to be independent and composable while still ensuring that result types align. A bit more on that here:https://failsafe-go.dev/type-safety/
mariusor|1 year ago
I found that states are not really required to know anything about internals of the executed code. All that a policy needs to know if the next state is an error or not, that's all.
I might have simplified the problem too much for my library to be useful in real life applications, but I still hold hope that a
stateFn func(context.Context) stateFn
is expressive enough for implementing the whole functionality.
If I may make another suggestion, I found that for more complicated flows, it is useful to be able to build a graph. I have made a rough approximation of a toold for my project based on parsing the go sources and inferring a state diagram from it. You can check it here: https://git.sr.ht/~mariusor/ssm/tree/master/item/cmd (Apologies for the lack of documentation, my work is much more recent than yours :D)