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;

wt., 18 cze 2024 o 23:36 Ville Voutilainen <ville.voutilainen_at_[hidden]>
napisał(a):

> On Tue, 18 Jun 2024 at 18:44, Mateusz Pusz <mateusz.pusz_at_[hidden]> wrote:
> >
> > Exactly!
> >
> >
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3045r1.html#why-dont-we-use-udls-to-create-quantities
>
> Perhaps the library could entertain providing literals for the SI base
> units, and not for combinations.
>
> >
> > wt., 18 cze 2024 o 17:43 Ville Voutilainen <ville.voutilainen_at_[hidden]>
> napisał(a):
> >>
> >> On Tue, 18 Jun 2024 at 18:38, Mateusz Pusz via Std-Proposals
> >> <std-proposals_at_[hidden]> wrote:
> >> >
> >> > Multiply syntax will always create a quantity. So if I write:
> >> >
> >> > auto q = 4 * deg_C;
> >> >
> >> > I will end up with a delta temperature equal to 4 K.
> >> >
> >> > quantity q = 4 * deg_C; // the same thing as above
> >> >
> >> > If I try:
> >> >
> >> > quantity_point qp = 4 * deg_C;
> >> >
> >> > I will get a compile-time error as a quantity_point is not implicitly
> constructible from the quantity.
> >> >
> >> > To create a quantity_point, I have to do one of the following:
> >> >
> >> > quantity_point qp1 = zeroth_degree_Celsius + 4 * deg_C;
> >> > quantity_point qp2(4 * deg_C, zeroth_degree_Celsius);
> >> > quantity_point qp3(4 * deg_C); // proper point origin provided by
> default
> >> >
> >> > All of the above will create a temperature point with a value equal
> to 277.15 K.
> >>
> >> ..and chrono allows creating objects of such types with a literal,
> >> whereas this library doesn't?
>