My previous question on this topic has been correctly identified as an instance of the XY problem.
I'm trying to create a resource management crate to decide who gets to rent the flooble. The public interface (currently) looks sort of like this:
pub struct Bid<T> {
max_bid: TokenPerNanoSecond,
budget: Token,
data: T
}
/// Returns a vector of tuples of (T, time of rent end, tokens spent)
pub fn who_rents_the_flooble<'a, T>(
mut bids: Vec<&'a mut Bid<T>>
) -> Vec<(T, NanoSecond, Token)> {
let mut output = vec![];
let mut now = NanoSecond::from(0);
// while bids.len() > 0 {
// run a mini auction to work out who wins
// increment now by the duration
// append winner's data, now and amount spent to output
// subtract amount spent from winner's budget
// remove bids with no budget left
// }
output
}
Token
, NanoSecond
and TokenPerNanoSecond
are newtypes of u64
with their arithmetic relationships fully defined; they're mostly present just because I'm bad at algebra, and don't want subtle bugs popping up because of my basic algebra mistakes and conflation of semantically different data.
T
is a purely opaque thing. It's the void *
of C callbacks, acting as a way for the caller to identify the relationship between what went in and what's come out.
However, Vec<&'a mut Bid<T>>
doesn't really do what I need it to do. In order to implement the "mini auction", I need to re-order a Vec<&'a Bid<T>>
copy of bids
, which requires taking ownership of the references and will leave me a little bit stuck when I next need to mutate the Bid
s.
What should my architecture look like?
If this isn't enough information, note that I'm trying to re-implement this bad code in Rust.