kevincox added a comment.
In https://phab.mercurial-scm.org/D6231#90744, @gracinet wrote: > That's an interesting idea. I expect it to solve my gripes with `ensure_undecided()` neatly. I'm not sure how it'd fare on the Python side, and probably wouldn't do it in the bindings to maintain compatibility, but I'll play with it a bit. Well the point is to force the caller to acknowledge the state change, but in python that isn't really possible because it is dynamically typed. What I would probably do is still implement the Rust part with multiple structs but then wrap it in an enum for the python API. Then each python method call turns into. fn do_thing() { match self { HasInfo(state) => state.do_thing() other => unreachable!("Invalid state for do_thing(). Expected HasInfo got {:?}.", other); } } And yes, this should allow you to avoid all of the `unwrap`ing since it would all be done at the API boundary. I think you could also propagate this to python by having the "state" transition methods return a new object. However because you can't ensure that the code drops the access to the previous object you would have to copy everything into the new object or ensure that you don't mutate shared state. The value is still lower here though because of the dynamic nature of python. > Maybe this could be a good topic for a follow-up ? Yeah, sounds reasonable. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D6231 To: gracinet, #hg-reviewers, kevincox Cc: durin42, kevincox, mjpieters, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
