Mateusz Pusz

> So just include the headers for the individual quantities you need e.g length Yes, I thought about it, but it would be hundreds of header files for ISQ. This...

Sure, I totally agree. This is why this library will always have C++20 compatibility (at least I hope so). Newer features will be used, though, when available to improve the...

I totally agree. I thought that the macros added some time to format.h should do the job. If not, we should fix it.

As stated in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3045r0.html#constructing-a-quantity: > Unit symbols introduce a lot of short identifiers into the current scope, which is why they are opt-in. A user has to explicitly “import” them...

> Maybe then best [to rewrite the first example I came across](https://github.com/mpusz/mp-units#tldr) to follow c++ best practice? I do not think we have to rewrite the examples to use using-declarations....

> The ctor syntax I would recommend is the quantity{value,unit} , but then I find myself thinking, I might just as well do it in a terser syntax: I played...

> If I got that wrong please correct me and I will apologise , so composability is not a problem here. There is no need to apologize. We are not...

I've just extended the documentation here: https://mpusz.github.io/mp-units/latest/getting_started/quick_start/#quantities.

_A side note on the compilation performance_ It is true that we can optimize the compilation performance, and we will do it for sure at some time in the future....

Sure! `unit_symbols` are just a construction helper and there are other ways to achieve the same goal without them. In cases where they cause issues, they should not be used....