Mateusz Pusz

So it seems that `isq::height` and `isq::width` should have a common type, compare with each other, be convertible, and be possible to add or subtract only in case of quantities...

@burnpanck, it is good to hear from you again 😃 > (That said, the last time I participated in the discussion about quantity types, we were still classifying "sibling types"...

BTW @burnpanck, you still have a few PRs open. Will you have some time to finish them soon?

I thought about this a bit more. Let's analyze such a simple tree: ```mermaid flowchart TD parent["parent (e.g., length)"] parent --- child["child (e.g., height)"] parent --- other_child["other_child (e.g., radius)"] ```...

> I would prefer if the results were consistent with the implicit casting rules. So if point can implicitly convert to point, then the difference of the two should be...

Yeah, I'm trying to wrap my head around this. My mental model is that, for example, for 1-D lengths, points represent an axis that can't be rotated, and we can...

I think that this discussion derailed a bit from the quantity point arithmetic subject, but I will add one more thing to it 😉 We have had the following issue...

This is great! Thanks! Regarding magnitudes, please note that they are meant to be implementation-defined. Only a few user-facing API things are public (construction helpers (mag, mag_ratio, and mag_power), concept,...

Could you please not squash or rebase the branch? It is impossible to track what changes between commits this way. I need to start reviewing all 2500 lines from scratch...

I try to review in LatTeX as it is easier to provide comments that way, and I also need to learn the syntax.