I agree with the namespace `std::units`, seems sensible to spilt out the feature, std::filesystem, std::chrono, etc.. provide good precedent for this sort of organization.

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

Well, I agree that it is better than `40 * absolute<deg_C>()`, at least it expresses the functional nature of the relationship.
But we kind of got sidetracked from the original point, which was using the actual type to do it instead of the gadget would have been better.

Being dependent of the gadget is not a solution I like, it forces you to do more work to define new units, it is more to know to use it.
But I really can’t argue with “I prefer to do this extra work because it feels safer to me”, it feels just like arguing personal preference at this point.
I guess it is called “general consensus” and not “make everyone happy”.


From: Mateusz Pusz <mateusz.pusz_at_[hidden]>
Sent: Friday, June 28, 2024 14:47
To: Tiago Freire <tmiguelf_at_[hidden]>
Cc: std-proposals_at_[hidden]; Charles R Hogg <charles.r.hogg_at_[hidden]>
Subject: Re: [std-proposals] On the standardization of mp-units P3045R1

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]<mailto: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]<mailto:mateusz.pusz_at_[hidden]>>
Sent: Friday, June 28, 2024 05:20
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Cc: Charles R Hogg <charles.r.hogg_at_[hidden]<mailto:charles.r.hogg_at_[hidden]>>; Tiago Freire <tmiguelf_at_[hidden]<mailto: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_lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals