Sorry if I didn't understand your intent. I thought that instead of unit
symbols you want to use UDLs. 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.

śr., 19 cze 2024, 09:43 użytkownik Ville Voutilainen <
ville.voutilainen_at_[hidden]> napisał:

> On Wed, 19 Jun 2024 at 09:30, Mateusz Pusz <mateusz.pusz_at_[hidden]> wrote:
> >
> > I did consider this, but it has many issues as well:
> > - It is not consistent across the library as we would need other ways to
> spell derived units or even base units in some cases (see below).
> > - It would be quite hard (or at least inconsistent with chrono) to
> specify and implement UDLs in such a way that they do not widen the types
> to the largest fundamental or floating-point type on arithmetic.
> > - There is no way to disambiguate SI second and CGS second
> > - With this even writing a unit of speed starts to be challenging.
> >
> > Right now we can type:
> >
> > quantity<m> length = 20 * m;
> > quantity<km/s> speed = 60 * km / s;
> >
> > With UDLs it would have to be something like this:
> >
> > quantity<si::metre> length = 20m;
> > quantity<si::kilo<si::metre> / si::second> speed = 60km / 1s;
>
> Fascinating. I don't quite understand what would cause that, instead
> of being able to do
> quantity<km/s> speed = 60km / 1s;
>