Operations on references

[milibopp]

I found that writing generic arithmetic with alga involves some extra clones. The reason is, that there is no way to apply operators to references. Therefore you have to pass ownership to the operator, which requires a clone, as soon as you need a value more than once.

For example, given two (large) vectors, a: T and b: U, where T: ClosedAdd<U>, I would like to be able to do all of these operations:

// possible today
a + b
a += b
// not possible without adding extra trait bounds
a + &b
&a + b
&a + &b
a += &b

That would probably require the ClosedAdd trait to be extended to this

trait ClosedAdd<Right = Self>:
    Sized +
    Add<Right, Output = Self> +
    for<'a> Add<&'a Right, Output = Self> +
    AddAssign<Right> +
    for<'a> AddAssign<&'a Right>
where
    for<'a> &'a Self: Add<Right, Output = Self>,
    for<'a, 'b> &'a Self: Add<&'b Right, Output = Self>
{}

Of course, this adds extra burden on trait implementors. It is also a backwards-incompatible change, as it breaks implementations that do not fulfill the extra bounds yet. (afaik, at least nalgebra should be fine.)

I would argue, that any arithmetic type should be able to handle these cases. Happy to hear a counter-example, but I can't really think of any yet.

[milibopp]

@sebcrozet any thoughts?

[Torrencem]

Unfortunately, Rust has an odd way of dealing with "where" constraints on traits. Adding this constraint to ClosedAdd, for example, would require that every time the user makes a function generic on T: ClosedAdd, they'd have to copy and paste the same "where for<'a>..." constraints on their functions. Take a look at this playground link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b1cb034e035155b015dc1bc89b11de9a

I've encountered this issue several times myself and am always annoyed by it. I can't seem to find the link right now,but there's an issue on the Rust repo that says that this should be fixed

[Torrencem]

I found it! It's this one: https://github.com/rust-lang/rust/issues/20671 since 2015 :(