Traits on slices

[mikkyang]

Right now, using slices as Vector trait objects don't work. This is because the Vector trait is implemented on [T]. Formerly it was implemented on &[T], but I realized this was incorrect. To receive the correct behavior there are two things I can think of immediately, outlined below. Similar things would be done to Matrix for coherency.

Option 1: Split the trait Vector into Vector and VectorMut

Splitting the traits, all of the immutable &self methods would remain in Vector and the mutable &mut self methods would be moved to VectorMut which will be a trait inheriting from Vector.

Function signatures that were previously:

fn axpy(alpha: &Self, x: &Vector<Self>, y: &mut Vector<Self>);

would become:

fn axpy(alpha: &Self, x: &Vector<Self>, y: &mut VectorMut<Self>);

Advantages:

• Actual operation function signatures just replace &mut Vector with &mut VectorMut and everything should work.

Disadvantages:

• This adds a level of indirection (not sure if right word) in the function calls. Essentially, the slices would work because the functions would take &&[T] rather than &[T].
• Breakage. People that were just using Vec and their own types would have to move the method.
• Repetitiveness. You already know that &mut types are mutable. I suppose Index and IndexMut are somewhat similar, though.

Option 2: Generics

Keep the traits the same, and add an unsized annotation to every function that takes a Vector.

Function signatures that were previously:

fn axpy(alpha: &Self, x: &Vector<Self>, y: &mut Vector<Self>);

would become:

fn axpy<V: ?Sized + Vector<Self>, W: ?Sized + Vector<Self>>(alpha: &Self, x: &V, y: &mut W);

Advantages:

• Traits remain the same, which means clearer traits.

Disadvantages:

• Function signatures become much, much more verbose. Especially because &x and &y maybe be different types, we can't constrict them both to the same type and have to specify trait bounds twice.

[mikkyang]

Option 2 was taken