Update comparison table

[chiphogg]

The main goal is to reflect some recent improvements in mp-units.

1. They upgraded their interfaces so that they now only contain
   unit-safe interfaces. This turns this row into a "tie".

2. They added new API functions to compare against 0. This is a
   different local optimum in design space for handling this problem
   than our solution, Zero. They considered Zero and declined to
   add it because of how it interacts with generic interfaces, but I
   still think Zero is a better solution on balance so I'll leave Au
   as "best".

I also re-assessed several other rows, the upshot of which is to turn 3
ties into "best" for mp-units.

1. Composability. NTTPs let mp-units write things like
   quantity<meter / second>, whereas we need to write something like
   Quantity<decltype(Meters{} / Seconds{})>. This is amazing!

2. Point types. Au assumes there's one origin (sometimes implicit)
   for each unit. This was really focused on the temperature use case,
   and maybe atmospheric pressure. mp-units has APIs to let users set
   the origin. This gives much richer possibilities for dealing with
   things like altitude, with lots of different possibilities for the
   origin. Au can kind of do this by making a new unit for each one,
   but I think mp-units' approach is more flexible.

3. Angles. The ability to support both dimensioned angles and
   "current SI" angles gives mp-units the edge.

I also switched boost units to "not assessed" on Abbreviated
Construction, because Mateusz mentioned they have the same syntax as
mp-units. I had assumed they didn't have anything here because they
don't have literals. If I can see a godbolt link of boost units code
that uses abbreviated construction, then I'll assess the rating based on
that link.

[chiphogg]

I wanted to get this table updated before CppCon.

Here's a zoomed out before/after of the table, for easy "blink" comparison:

Before:

After:

[mpusz]

1. Does Au support any user-provided representation type or just C++ fundamental types?
2. "Smart, unit-aware inverse functions" are missing for mp-units
3. Composability for Boost.Units could be improved as it supports composition of prefixes and units (i.e. 2.0*si::meters/si::second
4. Ease of migration would be really great in mp-units with feat: interoperability with other libraries redesigned mpusz/mp-units#495 (I plan to merge it during the weekend)
5. The only user-facing macro in mp-units provides C++20 backward-compatibility (the final interface is meant to benefit from C++23 this deduction)

[mpusz]

Point 4. above was merged today.

[chiphogg]

1. Does Au support any user-provided representation type or just C++ fundamental types?

We do, but it's not well tested --- nothing on the level of the Representation concept from mp-units. This is reflected in the "Rep variety" row.

2. "Smart, unit-aware inverse functions" are missing for mp-units

Added, thanks!

3. Composability for Boost.Units could be improved as it supports composition of prefixes and units (i.e. 2.0*si::meters/si::second

I did not realize this; thanks! Amusingly, I had obtained the old rating from the chart in P1935. 🙂

4. Ease of migration would be really great in mp-units with feat: interoperability with other libraries redesigned mpusz/mp-units#495 (I plan to merge it during the weekend)

Really cool how you can customize explicit/implicit conversions per type!

Does it support double-hop? e.g., can you implicitly initialize a std::chrono::nanoseconds from mp_units::quantity<mp_units::si::second, uint32_t>? Be aware that this can be tricky to get right, as there can be some unintended pitfalls that you're not likely to catch when you land it.

I'll call this "good" for both now since each library has a significant feature the other doesn't (assuming there's no double-hop in mp-units).

5. The only user-facing macro in mp-units provides C++20 backward-compatibility (the final interface is meant to benefit from C++23 this deduction)

Updated this row; thanks!