Date: Tue, 18 Jun 2024 17:02:27 +0200
I am not sure what you mean by "field types". Do you mean `year_month_day`?
For now, we follow the `duration` and `time_point` design. C++ developers
have been exposed to it for many years now, and it is successful in most
cases. This is why we believe that a similar abstraction with `quantity`
and `quantity_point` should also prove OK. Many people claim that affine
space abstraction is a mandatory feature of the units library.
wt., 18 cze 2024 o 16:57 Ville Voutilainen <ville.voutilainen_at_[hidden]>
napisaĆ(a):
> On Tue, 18 Jun 2024 at 16:54, Mateusz Pusz via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> > Temperatures are tricky, and there is no good default here. People often
> mean either a point or a difference, depending on the context. In case
> anyone has an idea on how to improve, we are open to feedback.
>
> Well, I wonder whether the design should follow chrono's example,
> where "field types" and "arithmetic types" are separate types,
> and you can do arithmetic only with the latter, and the former don't
> convert to the latter implicitly.
>
For now, we follow the `duration` and `time_point` design. C++ developers
have been exposed to it for many years now, and it is successful in most
cases. This is why we believe that a similar abstraction with `quantity`
and `quantity_point` should also prove OK. Many people claim that affine
space abstraction is a mandatory feature of the units library.
wt., 18 cze 2024 o 16:57 Ville Voutilainen <ville.voutilainen_at_[hidden]>
napisaĆ(a):
> On Tue, 18 Jun 2024 at 16:54, Mateusz Pusz via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> > Temperatures are tricky, and there is no good default here. People often
> mean either a point or a difference, depending on the context. In case
> anyone has an idea on how to improve, we are open to feedback.
>
> Well, I wonder whether the design should follow chrono's example,
> where "field types" and "arithmetic types" are separate types,
> and you can do arithmetic only with the latter, and the former don't
> convert to the latter implicitly.
>
Received on 2024-06-18 15:02:41