Implement operations for Quantity references

[iliekturtles]

impl Op<Quantity<...>> for Quantity<..> is already complete. Add the following reference implementations:

• [ ] impl<'a, 'b> Op<&'a Quantity<...>> for &'b Quantity<..>
• [ ] impl<'a> Op<&'a Quantity<...>> for Quantity<..>
• [ ] impl<'a> Op<Quantity<...>> for &'a Quantity<..>

[jacg]

Are there any difficulties or pitfalls here, or is it just a fairly mechanical process that simply requires finding the time to do it?

If it's the latter, I'll start chipping away at it.

If it's the former, I could also have a go, if you brief me.

[iliekturtles]

Should be completely mechanical.

Implementation would start with the following macros

https://github.com/iliekturtles/uom/blob/66d3e8586a734c15921779e8f3e06af40ccef365/src/system.rs#L588-L591

And you can compare against what the standard library is doing for inspiration on implementing for T and &T. https://doc.rust-lang.org/src/core/ops/arith.rs.html#117-133

Once the major traits are implemented we can go hunting to see if there is anything else like Sub that needs extra impls.

[jacg]

Implementation would start with the following macros [impl_ops!]

Just to be sure: Are you suggesting to add the implementations of the reference versions, to the bodies of those macros?

I don't quite understand the pattern inside the macro. First we have this group of 4:

• ....autoconvert! ... AddSubTrait
• not_autoconvert! ... AddSubTrait
• ....autoconvert! ... AddSubAssignTrait
• not_autoconvert! ... AddSubAssignTrait

followed by another group of 4:

• ....autoconvert! ... MulDivTrait
• not_autoconvert! ... MulDivTrait
• ................ ... MulDivTrait
• ................ ... MulDivAssignTrait

Why is there an asymmetry between the AddSub group and the MulDiv group?

[iliekturtles]

I apologize for taking so long to get to this. I'll look at the PR in a second to see what you've done so far. The original thought was to do something to the standard library and use a macro that accepts the type (T vs. &T) as a parameter.

The asymmetry is because multiply and divide allow for operating on the underlying storage type as well as the quantity. e.g. length * time and length * 3.0. Add/subtract require the same quantity on both sides of the operator. e.g. length1 + length2. The [not_]autoconvert! macros decide if the implementation supports operating on quantities with different base units.