Status of the project

[StefanoD]

Hi, I would like to ask how the status of the project is. There are some PRs which contain bug fixes and which has not yet been merged. The last merge was on Mar 3, 2023 which is almost a year since the last merge.

Does this project gets continued at least with bugfix maintenance?

[LawrenceStanton]

Rate it's time to fork it off and someone else can continue maintaining this.

[andipeer]

Do you know of any actively maintained fork where we could bundle our efforts to contribute?

[StefanoD]

We are heavily considering to switch to the Au library. Personally, I don't recommend any fork.

[andipeer]

In the draft for bringing units to std, there is written about @nholthaus:

In 2023, recognizing the limits of units, he joined forces with Mateusz Pusz in his effort to standardize his evolutionary dimensional analysis library [...]

So did the units library run into a dead end? Are there some technical limitations that prevent further development?

[StefanoD]

So did the units library run into a dead end? Are there some technical limitations that prevent further development?

Honestly, I think the alternatives are better.

[Guillaume227]

The library and the unification work gets mentioned in that cppcast episode a few months back : https://cppcast.com/physical_units_and_a_system_of_quantities/ I thought it was interesting to get more background.

[dpservis]

mp_units and Au do not support MSVC

[StefanoD]

mp_units and Au do not support MSVC

That's not true. If you look at the Au GitHub page, you'll see that the unit tests for MSVC 19.2 and 19.3 are passing. Further, Au only needs C++ 14 and MSVC has great C++ 20 support. So, C++ 14 shouldn't be any problem.

[dpservis]

mp_units and Au do not support MSVC

That's not true. If you look at the Au GitHub page, you'll see that the unit tests for MSVC 19.2 and 19.3 are passing. Further, Au only needs C++ 14 and MSVC has great C++ 20 support. So, C++ 14 shouldn't be any problem.

True, but if you go to the documentation you will see that it is only "best effort" support and they may drop it anytime.

That said, I do not like Au much, I opted for mp_units with my own workarounds to avoid the MSVC compilation errors, known debt that will be refactored as soon as the problems are sorted out

[StefanoD]

@dpservis The best effort support is explained on that page:

For example, if GitHub actions drops support for Windows Server 2019, we won’t be able to continue running GitHub workflows for MSVC x64 19.29. If that happened, we would have to move that configuration to the “Assumed Support” tier.

So, it seems to depend on GitHub. Further, the community can always send patches if something breaks. And I think that breakage is less likely with C++ 14 requirements.

Could you please also explain why you don't like Au?

[dpservis]

So, it seems to depend on GitHub. Further, the community can always send patches if something breaks. And I think that breakage is less likely with C++ 14 requirements.

No commitment is not enough, sorry

Could you please also explain why you don't like Au?

constexpr double angle_rad = degrees(angle_deg).in(radians); summarizes a lot of the things I do not like. The API is not natural when working with units, e.g. degrees(). Then also .in(radians) is the inverse. Furthermore, I cannot find enough examples in the documentation that are relevant to the things that I want to do.

[StefanoD]

@dpservis Not sure, if I can follow. in() is a safety-feature to make sure you retrieve the raw value in the correct unit. This is a plus for me. In a pull request from a collegue of mine, he retrieved in the units-lib with .value() the wrong unit type. The unit type was seconds, but what he actually wanted was milliseconds. He didn't noticed this, because the declaration of the variable was somewhere else and he thought it was milliseconds.

[dpservis]

Good point, .value() is another minus. My point is that I prefer the angle*rad notation. There are also several other nuances in the API.

[chiphogg]

Hi! I'm the primary author and maintainer of Au. I'm happy to answer any questions. And thanks very much for the candid feedback!

My point is that I prefer the angle*rad notation.

We support this as well, as of the 0.3.4 release from last December. This is the new "unit symbols" feature. So you could do something like the following.

// (In a `.cc` file, to avoid namespace pollution):
using au::symbols::rad;

double angle_rad;  // From somewhere
constexpr auto angle = angle_rad * rad;  // Same as `radians(angle_rad)`

Furthermore, I cannot find enough examples in the documentation that are relevant to the things that I want to do.

If you have any concrete examples of use cases we should consider documenting, let me know! I'm sure we have blind spots based on being more focused on the use cases we're more familiar with.

Meanwhile, we do have tutorials that can provide a gentle introduction to the library, supporting learning-by-doing --- I'm not sure if that would have been helpful for you.

No commitment is not enough, sorry

I can add some colour here and explain how we approach this tier of support.

We can't commit to supporting one particular version of MSVC forever, because having the ability to run that version in CI is out of our control. However, the commitment to supporting whatever MSVC version GitHub actions provides is stronger. We wouldn't lose total MSVC support unless GitHub actions dropped all MSVC versions. You'll have to make your own judgments on that one, but to me, it seems pretty unlikely.

I'm also puzzled that you're calling the lack of strongly committed MSVC support a dealbreaker for Au, yet you went with mp-units, where MSVC support is broken right now, and has been for many months. mp-units is a fantastic library, and I'm confident that MSVC support will return, but Au has CI-tested support for MSVC right now.

There are also several other nuances in the API.

If you happen to recall what they are, I'd love to hear more about them! Maybe they'll be tradeoffs that we made intentionally... but maybe they'll be simply defects that we could improve, which would be awesome. Even if they're intentional design decisions that we made, it's valuable for me to understand my potential users --- even/especially the ones that prefer other alternatives --- better.