How to overload methods in Rust.

Overloading methods is a commonly used feature in many programming languages. Before turning to further details, let me mention early, in Rust there exists no exact ‘overloading’ of functions. But nevertheless, Rust makes available some techniques that are of upmost importance to avoid code replication and at the same time ensure security as well as its glorified performance.

Note, this story assumes the reader to have some basic knowledge of Rust. If necessary you might find this a helpful introduction.

The problem:

Let us consider the following simple scenario. We want to create a small libraries Utils that operates on vectors (or matrices) and allows to compute the sine of a vector be component-wise application. That is, we want to write code of the form

let w = Utils::sin(&v);

Here v could be something like vec![1.0, 2.0] and w would be expected to become vec![(1.0).sin(), (2.0).sin()].

First approach:

This worked! But wait, this is written to only support vectors of f32‘s. We also want to support f64‘s or even vectors of vectors (matrices) like Vec<Vec<f32>>. By just adding a corresponding version to the impl of Utils results in the error

duplicate definitions with name `sin`:
duplicate definitionrustcE0201

Let us next see what kind of mechanism Rust provides for our scenario. You are also invited to contemplate how you would solve this in your favorite (statically typed) language.

Solution:

To solve our problem we will utilize Rust’s Trait system. The above situation is a very good example to remember for what reason traits do exist in Rust’s ecosystem.

We define the following trait:

pub trait Sin<T> {
   fn sin(v: &Vec<T>) -> Vec<T>;
}

This just replicates our method signature but using a generic type parameter T. But it provides much to our code: “Sine is now a trait”. Let us compare this to Rust’s internal trait Add. If a type implements Add, then we are able to use the operator + to connect instances of it: a + b. For sine though there is no internal way of stating something like “the type is Sine-able”. With the above trait we have added exactly this.

Now, we can implement the two versions of our utility function plus the matrix version:

Okay, runs as well!

One thing deems interesting to point out here. If a consumer includes our Utils as a module (say mod utils), none of both versions will be available on Utils without not doing a use utils::Sin. That is, the trait must be brought into context before being able to use it. This sounds cumbersome but adds very much security to our code! Assume, there is another declaration of Sin from another module. This way, you can be certain which one is being used in your code.

A second very neat thing Rust’s compiler is doing, it only adds those implementations to the final machine code that are actually used. So, if our consumer only uses Sin on Vec<f64>, only the corresponding Sin<f64> implementation is compiled.

Looking at the above code, beside all this advertisement of Rust, some might (hopefully) started complaining about the code replication. This impl for Sin<f32> and Sin<f64> structurally look the same. Of course, from a compilers way of looking at this and even from the runtime, these things are totally different (bit-level). Let us see next how Rust helps out here as well.

Avoiding code replication:

From a security point of view to write both versions for Sin<f32> and Sin<f64> looks correctly. From a developers perspective it looks bad since it introduces harder to maintain code. So, we could sum-up: On the one hand we want to have both implementations in the code but only want to write it once. Here comes Rust’s Macros into play that allows to make the compiler writing code for us. Let us see how this works:

All the impl have been replaced by the macro definition sin_impl_macro and further four application of it sin_impl_macro!…. The macro itself consists of two parts:

The one that provides implementations for Sin<T> and T being either f32 or f64,

And the other providing implementations for Sin<Vec<T>>,

As you can see, the code inside does only abstracts the use of the type variable T. The rest of both implementations are exactly the once as before.

Also, interesting is, we have here another sort of ‘overloading’. The macro when applied is matching the patterns supplied in the arms. That is,

sin_impl_macro!(f32);

sin_impl_macro!(f64);

are matched with ($T:tt) => …

and

sin_impl_macro!(Vec<f32>);

sin_impl_macro!(Vec<f64>);

with (Vec<$T:tt>) => …

I think we can be satisfied with the final product. Of course, macros are a nice help, but one should not overdo things with it. It can quickly become hard to understand. But let me mention, debugging works as before, since at the end, a macro is just writing code at compile time. Nothing else!

Thanks for reading!