> 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]<mailto: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]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals