如何有效地处理 rust 中不同具体类型的泛型类型？

Question

The main goal is to implement a computation graph, that handles nodes with values and nodes with operators (think of simple arithmetic operators like add, subtract, multiply etc..). An operator node can take up to two value nodes, and "produces" a resulting value node.

Up to now, I'm using an enum to differentiate between a value and operator node:

pub enum Node<'a, T> where T : Copy + Clone {
    Value(ValueNode<'a, T>),
    Operator(OperatorNode)
}

pub struct ValueNode<'a, T> {
   id: usize, 
   value_object : &'a dyn ValueType<T>
}

Update : Node::Value contains a struct, which itself contains a reference to a trait object ValueType , which is being implemented by a variety of concrete types.

But here comes the problem. During compililation, the generic types will be elided, and replaced by the actual types. The generic type T is also being propagated throughout the computation graph (obviously):

pub struct ComputationGraph<T> where T : Copy + Clone {
    nodes: Vec<Node<T>>
}

This actually restricts the usage of ComputeGraph to one specific ValueType .

Furthermore the generic type T cannot be Sized , since a value node can be an opqaue type handled by a different backend not available through rust (think of C opqaue types made available through FFI).

One possible solution to this problem would be to introduce an additional enum type, that "mirrors" the concrete implementation of the valuetype trait mentioned above. this approach would be similiar, that enum dispatch does.

Is there anything I haven't thought of to use multiple implementations of ValueType ?

update :

What i want to achive is following code:

pub struct Scalar<T> where T : Copy + Clone{
    data : T
}

fn main() {
   let cg = ComputeGraph::new();

   // a new scalar type. doesn't have to be a tuple struct   
   let a = Scalar::new::<f32>(1.0);

   let b_size = 32; 
   let b = Container::new::<opaque_type>(32);

   let op = OperatorAdd::new();

   // cg.insert_operator_node constructs four nodes: 3 value nodes  
   // and one operator nodes internally. 
   let result = cg.insert_operator_node::<Container>(&op, &a, &b);

} 

update

ValueType<T> looks like this

pub trait ValueType<T> {
    fn get_size(&self) -> usize;
    fn get_value(&self) -> T;
}

update

To further increase the clarity of my question think of a small BLAS library backed by OpenCL. The memory management and device interaction shall be transparent to the user. A Matrix type allocates space on an OpenCL device with types as a primitive type buffer, and the appropriate call will return a pointer to that specific region of memory. Think of an operation that will scale the matrix by a scalar type, that is being represented by a primitive value. Both the (pointer to the) buffer and the scalar can be passed to a kernel function. Going back to the ComputeGraph , it seems obvious, that all BLAS operations form some type of computational graph, which can be reduced to a linear list of instructions ( think here of setting kernel arguments, allocating buffers, enqueue the kernel, storing the result, etc... ). Having said all that, a computation graph needs to be able to store value nodes with a variety of types.

Answer 1

As always the answer to the problem posed in the question is obvious. The graph expects one generic type (with trait bounds). Using an enum to "cluster" various subtypes was the solution, as already sketched out in the question.

An example to illustrate the solution. Consider following "subtypes":

struct Buffer<T> {
   // fields
}

struct Scalar<T> {
   // fields
}

struct Kernel {
   // fields
}

The value containing types can be packed into an enum:

enum MemType {
   Buffer(Buffer<f32>);
   Scalar(Scalar<f32>);
   // more enum variants ..
}

Now MemType and Kernel can now be packed in an enum as well

enum Node {
   Value(MemType);
   Operator(Kernel);
}

Node can now be used as the main type for nodes/vertices inside the graph. The solution might not be very elegant, but it does the trick for now. Maybe some code restructuring might be done in the future.