Ville, thanks for the clarification.

I am not sure if we need one more entity in the library, which is also
quite expensive to standardize and has the issues I mentioned before. Also,
it will not create a `quantity_point` but a `quantity` type (consistently
with chrono UDLs creating `duration` and not `time_point`), so I am not
sure how it helps in solving the issue mentioned in this thread.

śr., 19 cze 2024 o 10:00 Ville Voutilainen <ville.voutilainen_at_[hidden]>
napisał(a):

> On Wed, 19 Jun 2024 at 10:52, Mateusz Pusz <mateusz.pusz_at_[hidden]> wrote:
> >
> > Sorry if I didn't understand your intent. I thought that instead of unit
> symbols you want to use UDLs.
>
> 60km / 1s;
>
> is using UDLs.
>
> quantity<km/s> speed = 60km / 1s;
>
> is using both unit symbols and UDLs. I have no problem with that, it's
> not a case of "instead".
>
> >Unit symbols are mostly useful as quantity construction helpers. They are
> useful, but they also introduce a lot of very short identifiers that may
> shadow user's variables. That is why they are opt-in in a separate
> namespace.
> >
> > If you wanted to have units, unit symbols, and unit UDLs, then yes, the
> code you provided would be correct. But still, there are some other issues
> ;-)
> >
> > Today we can write things like:
> >
> > auto w = 40 * isq::width[m];
> >
> > auto h = 10 * isq::height[m];
> >
> > to get specialized quantities of length. With UDLs it would be
> impossible.
>
> I'm not asking for UDLs as a replacement for unit symbols. I'm asking
> for them as an amendment, as a convenient way to to create a
> particular
> quantity_point.
>