Same object with different API faces at compile time?

Question

I have an object that can be in either of two modes: a source or a sink. It is always in one of them and it is always known at compile time (when passed the object you know if you are going to read or write to it obviously).

I can put all the methods on the same object, and just assume I won't be called improperly or error when I do, or I was thinking I could be make two tuple structs of the single underlying object and attach the methods to those tuple structs instead. The methods are almost entirely disjoint.

It is kind of abusing the fact that both tuple structs have the same layout and there is zero overhead for the casts and tuple storage.

Think of this similar to the Java ByteBuffer and related classes where you write then flip then read then flip back and write more. Except this would catch errors in usage.

However, it does seem a little unusual and might be overly confusing for such a small problem. And it seems like there is a better way to do this -- only requirement is zero overhead so no dynamic dispatch.

https://play.rust-lang.org/?gist=280d2ec2548e4f38e305&version=stable

#[derive(Debug)]
struct Underlying {
    a: u32,
    b: u32,
}

#[derive(Debug)]
struct FaceA(Underlying);

impl FaceA {
    fn make() -> FaceA { FaceA(Underlying{a:1,b:2}) }
    fn doa(&self) { println!("FaceA do A {:?}", *self); }
    fn dou(&self) { println!("FaceA do U {:?}", *self); }
    fn tob(&self) -> &FaceB {  unsafe{std::mem::transmute::<&FaceA,&FaceB>(self)} }
}

#[derive(Debug)]
struct FaceB(Underlying);

impl FaceB {
    fn dob(&self) { println!("FaceB do B {:?}", *self); }
    fn dou(&self) { println!("FaceB do U {:?}", *self); }
    fn toa(&self) -> &FaceA {  unsafe{std::mem::transmute::<&FaceB,&FaceA>(self)} }
}

fn main() {
    let a = FaceA::make();
    a.doa();
    a.dou();

    let b = a.tob();
    b.dob();
    b.dou();

    let aa = b.toa();
    aa.doa();
    aa.dou();
}

Answer 1

First of all, it seems like you don't understand how ownership works in Rust; you may want to read the Ownership chapter of the Rust Book. Specifically, the way you keep re-aliasing the original FaceA is how you would specifically enable the very thing you say you want to avoid. Also, all the borrows are immutable, so it's not clear how you intend to do any sort of mutation.

As such, I've written a new example from scratch that involves going between two types with disjoint interfaces (view on playpen).

#[derive(Debug)]
pub struct Inner {
    pub value: i32,
}

impl Inner {
    pub fn new(value: i32) -> Self {
        Inner {
            value: value,
        }
    }
}

#[derive(Debug)]
pub struct Upper(Inner);

impl Upper {
    pub fn new(inner: Inner) -> Self {
        Upper(inner)
    }

    pub fn into_downer(self) -> Downer {
        Downer::new(self.0)
    }

    pub fn up(&mut self) {
        self.0.value += 1;
    }
}

#[derive(Debug)]
pub struct Downer(Inner);

impl Downer {
    pub fn new(inner: Inner) -> Self {
        Downer(inner)
    }

    pub fn into_upper(self) -> Upper {
        Upper::new(self.0)
    }

    pub fn down(&mut self) {
        self.0.value -= 1;
    }
}

fn main() {
    let mut a = Upper::new(Inner::new(0));
    a.up();

    let mut b = a.into_downer();
    b.down();
    b.down();
    b.down();

    let mut c = b.into_upper();
    c.up();

    show_i32(c.0.value);
}

#[inline(never)]
fn show_i32(v: i32) {
    println!("v: {:?}", v);
}

Here, the into_upper and into_downer methods consume the subject value, preventing anyone from using it afterwards (try accessing a after the call to a.into_downer()).

This should not be particularly inefficient; there is no heap allocation going on here, and Rust is pretty good at moving values around efficiently. If you're curious, this is what the main function compiles down to with optimisations enabled:

mov edi, -1
jmp _ZN8show_i3220h2a10d619fa41d919UdaE

It literally inlines the entire program (save for the show function that I specifically told it not to inline). Unless profiling shows this to be a serious performance problem, I wouldn't worry about it.