It looks like scip maintains a state machine internally. These states should probably be reflected at the type level in rust. Instead of a single Model type, there should probably be at least an UnsolvedModel and a SolvedModel, and probably more.
This should also help you have less Result in your return types. If you can guarantee at the type level that a particular C function call will not fail, then you can turn a faillible_call()? into a faillible_call().expect("We are in state X, which meets all the preconditions of function faillible_call")
See https://willcrichton.net/rust-api-type-patterns/state_machines.html
It looks like scip maintains a state machine internally. These states should probably be reflected at the type level in rust. Instead of a single
Modeltype, there should probably be at least anUnsolvedModeland aSolvedModel, and probably more.This should also help you have less
Resultin your return types. If you can guarantee at the type level that a particular C function call will not fail, then you can turn afaillible_call()?into afaillible_call().expect("We are in state X, which meets all the preconditions of function faillible_call")Originally posted by @lovasoa in https://github.com/mmghannam/russcip/issues/15#issuecomment-1436116362