Recommendations about references to other field of the same struct

help
1

I've these types that compile (I'm surprised that using the references in the same struct compiles), but I can't use them later.

Here it's the whole example:

use futures::{stream, StreamExt};
use std::{
    collections::{BTreeMap, HashMap},
    vec::IntoIter,
};

trait Processable {
    fn code(&self) -> String;
    fn priority(&self) -> u32;
}

struct Operation {
    queue: stream::Iter<IntoIter<Item>>,
}

struct Item {
    code: String,
    priority: u8,
}

struct Processor<'a, T: Processable> {
    processables: HashMap<String, T>,
    priority: BTreeMap<u32, Vec<&'a T>>,
}

So, my question is, what's the best approach?

  • Pin: I don't fully understand it, so I'd rather avoid it unless someone explain it to me.
  • Rc: It's !Send, so I couldn't use it because I'm using async code. Apart from that, allocating hundreds or thousands of Rc + Weak doesn't looks good.
  • Arc: I don't need Sync, Mutex, etc.
  • Indexes: Storing the indexes or the codes in the BTreeMap is simple but it means looking up in the HashMap for everything, instead of just accessing the T through a reference.

What would you do?

2

Another possible approach are crates like ouroboros that help you construct self-referential structs in safe Rust. I personally would probably look into whether I can avoid the Processor struct while still having an intuitive API for my users, letting them decide where to store the priority queue and the processables table.

3

I would avoid self-referential structures. 99% you don't really need them, and are just trying to reimplement familiar patterns from other languages.

The proper way to do it in Rust is to separate the storage from the data that references it. Another option is to use keys/handles instead of references. E.g. in your example, make priority: BTreeMap<u32, String> instead of BTreeMap<u32, &T>. Or you could even introduce a separate field data: Vec<T>, and make other fields store indices into that vector, e.g. priority: BTreeMap<u32, usize>, processables: HashMap<String, u32>. The extra indexing isn't likely to meaningfully affect your performance, but it will make it much easier to write & reason about the code.

There are various crates which make this pattern easier to use, but I can't give any more specific recommendations without more information about your problem.

4 Likes
4

Thank you.

I'd like to avoid external dependencies in this case, so Ouroboros is out.

I've been thinking on an alternative:

struct Processor<T: Processable> {
    processables: HashMap<String, (u32, usize)>,
    priority: BTreeMap<u32, Vec<T>>,
}

The most common operations involve the priority queue, so storing items directly in a BTreeMap would suffice for most cases.

The HashMap should only be used for operations that require locating a specific item by its code: the key is the code, and the value contains the priority and the index within the Vec (multiple items can have the same priority but will be sorted by date or another criterion).

I think that I'm going to try something like this because it looks quite simple and I don't see any red flag :slight_smile: .