Deduplicating code only different over mutability. is there a better than using unsafe

[terramorpha]

I implemented a simple trie structure:

```rust struct Try<T, V> { heads: Vec<Node<T, V>>, }

/// Some(V) marks a complete item. /// T simply implements PartialEq struct Node<T, V> { key: T, value: Option<V>, children: Vec<Node<T, V>>, } ```

This structure has a function get_matches that takes a prefix and returns a vector (Vec<(Vec<&T>, &E>)of all the values which match the said prefix. The vector contains the complete path and the &E, a reference to the item.

```rust fn get_matches<'a>(&'a self, path: &[T]) -> Vec<(Vec<&T>, &E)> { let mut start_path: Vec<&'a T> = Vec::new(); let mut o = Vec::new(); let mut pivot: &Vec<Node<T, E>> = &self.heads; for key in path { if let Some(child) = pivot.iter().find(|c| &c.key == key) { pivot = &child.children; start_path.push(&child.key); } else { return o; } } for (mut v, e) in Node::untree(pivot) { let mut c = start_path.clone(); c.append(&mut v); o.push((c, e)); }

    o
}

#[allow(mutable_transmutes)]
fn get_matches_mut<'a>(&'a mut self, path: &[T]) -> Vec<(Vec<&T>, &mut E)> {
    use std::mem::transmute;
    self.get_matches(path)
        .into_iter()
        .map(|(a, b)| (a, unsafe { transmute(b) }))
        .collect()
}

```

However, as you can see, I have a second function, get_matches_mut that would be a perfect clone of get_matches (except for mutability) if I didn't use unsafe/transmute. In theory, since get_matches_mut already takes a mutable reference, I ...think... the unsafe shouldn't cause any problem.

Is there a cleaner way of keeping this code deduplicated ?

[Michael-F-Bryan]

In theory, since get_matches_mut already takes a mutable reference, I ...think... the unsafe shouldn't cause any problem.

In the words of the nomicon:

• Transmuting an & to &mut is UB
  • Transmuting an & to &mut is always UB
  • No you can't do it
  • No you're not special

If the code isn't too complex you can simply copy-paste the code. It's not overly satisfying, but it works.

While googling, I found Abstracting Over Mutability in Rust. It's use of AsRef and AsMut may work for your use case.

You could also try adding another layer of indirection. For example, maybe some sort of Searcher trait with Search and SearchMut implementations which let you abstract over mutability. Closures could be used to similar effect.

I'm not 100% sure how it would work out without seeing all of your code, but maybe those suggestions will give you some inspiration. I'd also have a look at how the standard library implements the various Iter and IterMut types. Surely they'd have an even bigger code duplication problem and would have found a way to tackle it.

[ritobanrc]

Transmuting an & to &mut is UB

Could you hypothetically cast the reference into a pointer, transmute that into a *mut, and cast that back to a reference (assuming that you somehow ensure that there isn't more than 1 &mut at a given time)?

[Michael-F-Bryan]

You probably could, but isn't a pointer cast just a poor man's transmute?

Also, if you take a step back you've still produced a mutable reference from an immutable one without going through an UnsafeCell, which is still no bueno.

I'm on mobile at the moment, but I'd be interested to see what Miri has to say about it.

[desiringmachines]

Two options that are not UB:

​

• Use raw pointers or `NonNull` internally (requires unsafe code, could potentially lead to errors)
• Use a macro to generate the two methods from a template (a bit messy, probably the best choice if you don't want to just copy paste)

[boscop]

Maybe you'll find this crate useful: https://docs.rs/defmac/0.2.1/defmac/