Proposal: let Solver hold Storage directly

[nahla-nee]

I wanted to gauge interest in this proposal before writing a PR for it, but I think it would make sense to have the solver hold storage directly and to add the ability to create values and constants to the solver. This would make it a bit more ergonomic to pass data around as you don't have to pass both the solver and storage in situations where you want to make variables and set assertions on them. It would also help simplify the api a bit as then the solver can (if desired) handle making its own storage which hides implementation details that the user might not care about away. Would this be something desirable for this library?

[oeb25]

Yes I think improving ergonomics would be great. If you want to have a go at implementing this be my guest!

I don't remember the exact reason for not doing this initially, but I think there might pop up some issues with the lifetime of storage vs the solver. Specifically the fact that the solvers methods often take &mut self, while the storage hands out &'st's all over the place. If the lifetime of solver and storage were to be the same we would have an issue, but if you find a way to mitigate this I think it would be great!

Let me know if there's any questions I can answer in the process, or if you hit any problems along the way.

[nahla-nee]

Sorry for the late response, life got away from me a bit and I was busy with travel. I do see the issue when it comes to that now, it would be possible to get around this by putting the solver's modifiable fields in a refcell, but I don't know if that would be a desirable solution, or if it would be worth the trade off. Do you have any thoughts about this?

Alternatively, and admittedly this is a strange way of doing it, something like this could be possible:
https://gist.github.com/nybble41/cf1390615ad2f759ce30c650b66bbb89