See mpusz/mp-units#615 for ideas.
The problem is that there are certain unit conversions that are simply impossible in Au currently, safety checks or no. Like, we can't convert between radians, and degrees or revolutions. We have no way to form that computation in integral types.
The solution would be to "lift" the variable to be converted into a double-wide integer. Then we could multiply it by the representation of, say, $2^N M$ for a conversion factor $M$ (assuming single-width is $N$ bits). Finally, we discard the least-significant $N$ bits.
For a type like int64_t that doesn't have any twice-as-wide target, we would need to implement a manual fallback with separate int64_t / uint64_t variables for the high and low bits.
Besides unlocking computations we can't currently do, it should also be more efficient and less prone to overflow.
Once #387 is complete, it will expose this deficiency more acutely. We can live with that for the 0.5.0 release, but it would be nice to get it in the next one.
See mpusz/mp-units#615 for ideas.
The problem is that there are certain unit conversions that are simply impossible in Au currently, safety checks or no. Like, we can't convert between radians, and degrees or revolutions. We have no way to form that computation in integral types.
The solution would be to "lift" the variable to be converted into a double-wide integer. Then we could multiply it by the representation of, say,$2^N M$ for a conversion factor $M$ (assuming single-width is $N$ bits). Finally, we discard the least-significant $N$ bits.
For a type like
int64_tthat doesn't have any twice-as-wide target, we would need to implement a manual fallback with separateint64_t/uint64_tvariables for the high and low bits.Besides unlocking computations we can't currently do, it should also be more efficient and less prone to overflow.
Once #387 is complete, it will expose this deficiency more acutely. We can live with that for the 0.5.0 release, but it would be nice to get it in the next one.