Avoiding code repetition for mutability

help
1

I I have written a Visitor for crawling over a large data structure. The
whole thing is fairly long (about 700loc).

The problem is that the entities it passes around are currently
references and I now have a use case which needs to mutate them. I am
not terribly keen on duplicating the code for obvious reasons. However allowing the mutability generally breaks other use cases.

I know that I can't make the code generic over the mutability which is
what I would really need. It seems to me the only solution is to macro
out the code. I could generate a version with mutable reference and a
version with immutable versions.

Have I missed another option? Is there macro out there for achieving
this already?

2

You could make the visitor generic over the reference type and then write code against a trait that may or may not be implemented over a mutable reference. You can also provide default implementations for the trait methods, potentially getting rid of large amounts of duplicated code: Playground

pub trait Visit {
    type Ref<'a, T: 'a>: Deref<Target = T>; // the reference type, mutable or immutable
    
    fn visit_string(&mut self, value: Self::Ref<'_, String>) {
        dbg!(&*value);
    }
    fn visit_u32(&mut self, value: Self::Ref<'_, u32>) {
        dbg!(&*value);
    }
}

struct Visitor;

impl Visit for Visitor {
    type Ref<'a, T: 'a> = &'a T;
}

struct VisitorMut;

impl Visit for VisitorMut {
    type Ref<'a, T: 'a> = &'a mut T;
}
3

That's really interesting. I have given this a go with something a bit closer to my code base -- I am using a Visitor will empty implementations, then a Walker which contains the tree traversal logic. In my real code, the Walker was a concrete implementation, so I have tried to move that also to a trait and use the same associated type. But, I can't get Rust to unify the types between the two traits, so it does not compile at the moment. What am I doing wrong?

4

In a default impl, how could the compiler possibly know the concrete associated type? Generics have to work with every eligible type (including Self) once they pass type checking, so "maybe this associated type will be OK for some concrete impls" isn't something the compiler base type checking on.

V::Ref<'a, T> may be any type; you can't pass a &String or a Self::Ref<'a, T> where a Ref<'a, String> is expected, because there's no guarantee whatsoever they are the same type.

The Ref associated type of the Walk trait is superfluous; the code can only ever work if it's exactly the same as V::Ref. So remove it. Once you remove it, you can see that the following line (for example) is nonsensical:

    fn nodea(&mut self, v: V::Ref<'_, NodeA>) {
        self.visit().visit_nodea(v);
        self.string(v.a_string); // <- nonsense
    }

because 1. you are trying to pass the string by value, which isn't possible directly since it's a non-Copy type behind a reference; and 2. if V::Ref is mutable, you can't get a mutable reference from a place behind an immutable one. So this simply can't work, ever.

5

Oh, I understand why it isn't working. I mean, the equivalent line in my real code looks like this:

pub fn dociri(&mut self, e:&DocIRI<A>) {
    self.0.visit_dociri(e);
    self.iri(&e.0);
}

So, the mutability of the data structure is specified in two places -- the formal paramters to the method, and in the tree walking invocation.

What I don't see is a solution. The design pattern works perfectly well with both mutable and immutable references, but I cannot see how to make it do both, other than a macro. And having thought about the macro since I posted, I think even that requires a proc macro. Or give up and just duplicate the code.

6

You want to project a field with mutability based on the mutability of the reference it's behind. You'll have to create additional trait(s) for the projections.

7

It may still be possible if you pack enough reference-like functionality into a trait. (Whether it's worth it or not is another question).

Generic reference-like trait:

pub trait GenRef {
    type Ty<'a, T: 'a>: Deref<Target = T>;
    fn reborrow<'r, T>(r: &'r mut Self::Ty<'_, T>) -> Self::Ty<'r, T>;
    fn a_string(node: Self::Ty<'_, NodeA>) -> Self::Ty<'_, String>;
    fn b_string(node: Self::Ty<'_, NodeB>) -> Self::Ty<'_, String>;
}

pub struct Shared;
impl GenRef for Shared {
    type Ty<'a, T: 'a> = &'a T;
    // ...
}

pub struct Mut;
impl GenRef for Mut {
    type Ty<'a, T: 'a> = &'a mut T;
    // ...
}

Make Visit generic over generic reference type:

pub trait Visit<Ref: GenRef> {
    fn visit_nodea(&mut self, value: Ref::Ty<'_, NodeA>) {
    // ...
    }
}

And Walk, unifying the generic reference type with the V: Visit parameter:

trait Walk<Ref: GenRef, V: Visit<Ref>> {
    fn nodea(&mut self, mut v: Ref::Ty<'_, NodeA>) {
        self.visit().visit_nodea(Ref::reborrow(&mut v));
        self.string(Ref::a_string(v));
    }
    // ...
}
1 Like
8

Ah, okay, yes. Factor out the reference call to a third generic. That saves re-writing the visitor and walker but at the cost of still duplicating the call itself in GenRef. Oh dear.

I think that code duplication is probably the way forward at this point.

Thanks for your help! I've learned about the type system.

9

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.