Thoughts on some Rust implementations

[Connor-GH]

So as seen so far in the examples, Rust can diverge a bit in its implementation from the C++ version if it means that it is more ergonomic for Rust and maintains the original meaning and semantics of the C++ version. After all, the goal here is to wrap the library, not reinvent the wheel.

With that being said, I have thought about some potential ugly points of the library so far.

hpx_ends_with(&[i32], &[i32]) was the first thing that caught my eye. Of course we know that this should be a generic, so I will leave that idea alone for now. The main pressing issue is the ergonomics of it. Wouldn't it be better to do something like hpx_ends_with(&self, &[i32])?

I am pretty sure it's not normal for an API to impl a trait for Vec and such, but it could be an easy gateway to generics. Examine:

trait Hpx {
    fn hpx_ends_with(&self, vec1: &[i32]) -> bool;
}

impl Hpx for Vec<i32> {
    fn hpx_ends_with(&self, vec1: &[i32]) -> bool {
        hpx_sys::ffi::hpx_ends_with(self.as_slice(), vec1)
    }
}

This is called using vec![1, 2, 3].hpx_ends_with(&[3]). Now imagine, we can now do impls for every type! f64, f32, i32, u32, i64, u64, and more!

The alternative, of course, is wrapper types or keeping the API as is and maintaining versions of the same function for every type.