-1

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 Bids.

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.

wizzwizz4
  • 6,140
  • 2
  • 26
  • 62
  • 1
    Why not just take in `Vec>`? – Shepmaster Jun 25 '19 at 18:31
  • @Shepmaster I thought of that about 2 hours ago, and it seems to have solved most of the problems. I was going to finish writing the program before writing up an answer, just to be sure. – wizzwizz4 Jun 25 '19 at 19:22

1 Answers1

0

All of these problems can be solved simply by taking ownership of the vector; your prototype should look like this:

pub fn who_rents_the_flooble<T>(
    mut bids: Vec<Bid<T>>
) -> Vec<(T, NanoSecond, Token)>

Passing by value, not by reference, solves the problem.

wizzwizz4
  • 6,140
  • 2
  • 26
  • 62