Ndtyjky

I have a struct of which precisely two versions exist. That is, the struct has an attribute describing which version it is (a bool or enum with two variants) which is passed as an argument in the constructor. Which version the struct will have is known at compile time. In the majority of the methods of this struct, a corresponding method (on an attribute of this struct) is called, depending on the value of the attribute. This results in many if-statements throughout the impl of this struct.

I considered moving all of the code into a trait, but this didn't seem appropriate: dynamic dispatch is not necessary, almost all methods will not have the self parameter and setters / getters for all attributes will be required. I'd still be left with two identical struct declarations. Also, the trait doesn't describe any generic behavior that other structs should implement.

It would be ideal if I could instead create a generic version of this struct, and instantiate one of the two versions. To make, for lack of a better word, two "sub-types" of my struct, with only a single method that has different behavior. Is such a thing possible?

It concerns a performance critical application, and the methods on this struct will be called many times. It it wasn't for maintainability, I would just copy all code. I would create two almost identical structs, where inside the methods, there is either one version of an external method being called, or the other.

Use a trait for behavior that has multiple implementations. There's many combinations of ways you can use them, here's one:

use std::marker::PhantomData;



trait Core {

    fn print();

}



#[derive(Debug, Default)]

struct PrintA;

impl Core for PrintA {

    fn print() {

        print!("a")

    }

}



#[derive(Debug, Default)]

struct PrintB;

impl Core for PrintB {

    fn print() {

        print!("b")

    }

}



#[derive(Debug, Default)]

struct Thing<C>(PhantomData<C>);



impl<C: Core> Thing<C> {

    fn common() {

        print!(">");

        C::print();

        println!("<")

    }

}



fn main() {

    Thing::<PrintA>::common();

    Thing::<PrintB>::common();

}

Or another:

trait Core {

    fn select<'a>(left: &'a i32, right: &'a i32) -> &'a i32;

}



#[derive(Debug, Default)]

struct Left;

impl Core for Left {

    fn select<'a>(left: &'a i32, _right: &'a i32) -> &'a i32 {

        left

    }

}



#[derive(Debug, Default)]

struct Right;

impl Core for Right {

    fn select<'a>(_left: &'a i32, right: &'a i32) -> &'a i32 {

        right

    }

}



#[derive(Debug, Default)]

struct Thing<C> {

    kind: C,

    left: i32,

    right: i32,

}



impl Thing<Left> {

    fn new_left(left: i32, right: i32) -> Self {

        Self {

            left,

            right,

            kind: Left,

        }

    }

}

impl Thing<Right> {

    fn new_right(left: i32, right: i32) -> Self {

        Self {

            left,

            right,

            kind: Right,

        }

    }

}



impl<C: Core> Thing<C> {

    fn add_one(&self) -> i32 {

        self.select() + 1

    }



    fn select(&self) -> &i32 {

        C::select(&self.left, &self.right)

    }

}



pub fn l() -> i32 {

    let l = Thing::new_left(100, 200);

    l.add_one()

}



pub fn r() -> i32 {

    let r = Thing::new_right(100, 200);

    r.add_one()

}

Of note, this last example compiles down to the following LLVM IR:

define i32 @_playground_l() {

start:

  ret i32 101

}



define i32 @_playground_r()  {

start:

  ret i32 201

}

I considered moving all of the code into a trait, but this didn't seem appropriate: dynamic dispatch is not necessary, almost all methods will not have the self parameter

• traits don't imply dynamic dispatch. See monomorphization.


• trait methods don't require self
  

It it wasn't for maintainability, I would just copy all code

Sounds like a place that macros might be a fit, if you cannot handle traits.