Yes, I proposed that before, but that is no longer the case. With the new
`delta` that is a functor, it would not be the right approach. So for the
2-parameter constructor we come back to the old design where you just
provide a value and a unit.

std::quantity<si::degrees_celsius, double> myVar{30, *deg_C*};

> the relationship is better expressed functionally, i.e. deg_C(40).

Good, so now you can type `delta<deg_C>(40)` or `absolute<deg_C>(40)` to
geta point.

And yes, we can definitely entertain LEWG to bikeshed `quantity` name. We
can propose `delta_quantity`, `quantity_diff`, and so on, but it will make
daily life of working with 99% of all other quantities harder. Another
possibility is that if we decide to put everything a namespace like
`std::units` (instead of just `std`) we could end up with types like
`std::units::delta` (instead of `quantity`) and `std::units::point`
(instead of `quantity_point`). With that, additional "gadgets" may not be
needed anymore.

pt., 28 cze 2024 o 03:23 Tiago Freire <tmiguelf_at_[hidden]> napisał(a):

> > Well, you do not have to use any "gadgets" during the construction if
> you do not like to. You can always use a 2-parameter constructor that takes
> a number and a unit. As Chip mentioned, taking only a unit is considered a
> safety issue, which is why it is not allowed in the library.
>
>
>
> I disagree that you don’t have to use a gadget.
>
>
>
> std::quantity<si::degrees_celsius, double> myVar = 30 * *delta(deg_C)*;
>
> std::quantity<si::degrees_celsius, double> myVar{30, *delta(deg_C)*};
>
>
>
> Has the same gadgets at play, 2 of them, one for *deg_C* and another one
> for *delta*.
>
>
>
> And it is the relationship with the gadget that led to the question in the
> first place.
>
>
>
> While representing any other unit, for example 40m, using the gadget as 40 **
> m* does indeed make physical sense as 40m = 40 * 1m (i.e. forty times one
> metre)
>
> That does not happen with degrees celsius or fahrenheit, as 40°C does not
> mean 40 * 1°C (i.e. forty times one degree celsius), the relationship is
> better expressed functionally,
>
> i.e. deg_C(40)
>
>
>
> Think of it in terms of having a physical measuring device which has a
> gauge in it, 40 is the number indicated on the gauge.
>
>
>
> But you have deprived yourself of this ability because of the way the
> gadget mechanism works.
>
>
>
>
>
> I would argue that would be better if your type was more transparent. I.e.
> make it clear to the user exactly what type of “quantity” it is, instead of
> the currently recommended usage which is to CTAD it away,
>
> not tell users what they are getting and instead having deduce what they
> would expect to get based on a chain of operations.
>
>
>
> You may argue that this was done for “safety” citing examples of ways that
> I don’t think are that unsafe regarding how I usually work and the tools I
> have available to address those problems,
>
> while disregarding others.
>
>
>
> Although the issue is one of usability in this case (and not a gotcha as
> it was the other one), we must not pretend that it is a choice, based on a
> personal preference.
>
>
>
>
>
> *From:* Mateusz Pusz <mateusz.pusz_at_[hidden]>
> *Sent:* Friday, June 28, 2024 05:20
> *To:* std-proposals_at_[hidden]
> *Cc:* Charles R Hogg <charles.r.hogg_at_[hidden]>; Tiago Freire <
> tmiguelf_at_[hidden]>
> *Subject:* Re: [std-proposals] On the standardization of mp-units P3045R1
>
>
>
> Well, you do not have to use any "gadgets" during the construction if you
> do not like to. You can always use a 2-parameter constructor that takes a
> number and a unit. As Chip mentioned, taking only a unit is considered a
> safety issue, which is why it is not allowed in the library.
>
>
>
> czw., 27 cze 2024 o 13:53 Tiago Freire via Std-Proposals <
> std-proposals_at_[hidden]> napisał(a):
>
> > In your specific example, this would be less likely because you've
> included the full unit name in your alias. However, not everyone wants to
> do this --- often, people want to give it a more generic alias, like
> `temperature`. Preventing this constructor from a single value (even when
> `explicit`), and making sure that every option forces the user to name the
> unit explicitly at the callsite, preserves unit safety, and reduces
> cognitive load.
>
>
>
> I think you focused too much on the alias part, while the important part
> is a fully named type. In many codes bases the rule to explicit type out
> your types are a thing.
>
> If I can fully type out the type that I want, why shouldn’t I be able to
> use it?
>
> Why exactly do I need a separate gadget to create that type?
>
> Talking about a mental effort, it is not enough to know the type that you
> want, you also need to lookup the right gadget (whose name has nothing to
> do with the type you are trying to construct) in order to construct your
> type,… what? Why?
>
>
>
> This doesn’t have the confusing problem that “30 * deg_C” feels wrong,
> because it is wrong, it’s not a multiplication why do you write it as a
> multiplication?
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>