derive_more
derive_more copied to clipboard
Forward Add, AddAssign, Sub and so on should use generics
#[derive(Add, AddAssign, Sub, SubAssign)]
struct Example(usize);
should generate
impl<T> Sub<T> for Example
where
usize: Sub<T, Output = usize>,
{
type Output = Self;
#[must_use]
#[inline]
fn sub(self, rhs: T) -> Self::Output { Self(self.0.sub(rhs)) }
}
impl<T> SubAssign<T> for Example
where
usize: SubAssign<T>,
{
#[inline]
fn sub_assign(&mut self, other: T) { self.0.sub_assign(other); }
}
impl<T> Add<T> for Example
where
usize: Add<T, Output = usize>,
{
type Output = Self;
#[must_use]
#[inline]
fn add(self, rhs: T) -> Self::Output { Self(self.0.add(rhs)) }
}
impl<T> AddAssign<T> for Example
where
usize: AddAssign<T>,
{
#[inline]
fn add_assign(&mut self, other: T) { self.0.add_assign(other); }
}
which would make the code a lot more flexible, than
impl ::core::ops::Add for Example {
type Output = Self;
fn add(self, rhs: Self) -> Self::Output {
Self(self.0.add(rhs.0), self.1.add(rhs.1))
}
}
To be clear the goald of this request would be to allow for:
assert_eq(Example(1) + 3i32, Example(4))
I think it makes sense to have this feature, but definitely behind an attribute (e.g. #[add(forward)])
To be clear the goal of this request would be to allow for
Yes
A similar addon can be useful for (Partial)Eq and (Partial)Ord.
I think that I've hit an issue that is related to this. Mul and Add doesn't generate the same thing, and I'd like the Mul to ressemble the Add. Let me see if I can quickly amend this..
Removing this from 1.0 milestone as this doesn't have to be a breaking change.
Would this also be the solution for math operations not generating implementations that handle references?
let e = Example(3);
assert_eq(Example(1) + &e, Example(4))
Obviously non-sensical in the toy example but I had it come up & the workaround I have is to sprinkle clone all over the place or make the types trivially copyable and I'm worried about the performance of the generated code vs having an add defined to work with references (maybe I'm overthinking it and the optimizer elides it all anyway?).
@vlovich I'm not sure that the proposal here would address that. But we do have a separate issue for specifically the usecase you're describing: #156