Date: Thu, 27 Jun 2024 08:43:40 +0000
What I would really like to do is:
quantity_point<si::degrees_celsius, double> q1{40.};
so that I can use it as:
using degrees_celsius = quantity_point<si::degrees_celsius, double>;
degrees_celsius q1{40.}; //Its 40 degrees celsius
But at this point it is completely off the table for issues you already tried to address.
This problem is infectious, and it is going to keep following you everywhere.
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Mateusz Pusz via Std-Proposals
Sent: Wednesday, June 26, 2024 22:17
To: std-proposals_at_[hidden]
Cc: Mateusz Pusz <mateusz.pusz_at_[hidden]>
Subject: Re: [std-proposals] On the standardization of mp-units P3045R1
During the discussion in the SG6 it was raised that that `30 * absolute<deg_C>` feels wrong, and I tend to agree with that. This was the only usage of `absolute` so, if multiply syntax should not use it, the `absolute` can be removed. After that, `30 * delta<deg_C>` looks like a hack and not a feature.
I am looking for some other solutions that would help here. Maybe we should:
- disallow the multiply syntax for offset units (K, deg_C, deg_F),
- change `delta` to be a functor and call it as `delta<deg_C>(20)` which produces a `quantity`
- re-add `absolute` to create a `quantity_point` with the same syntax (e.g., `absolute<deg_C>`)
With the above, we would end up with the following helpers:
```cpp
quantity q1 = 40 * m;
quantity q2 = delta<m>(40);
quantity_point q3 = absolute<m>(40);
quantity q4 = 40 * deg_C; // Compile-time error
quantity q5 = delta<deg_C>(40);
quantity_point q6 = absolute<deg_C>(40);
quantity q7 = 40 * isq::thermodynamic_temperature[deg_C]; // Compile-time error
quantity q8 = delta<isq::thermodynamic_temperature[deg_C]>(40);
quantity_point q9 = absolute<isq::thermodynamic_temperature[deg_C]>(40);
```
With the proposed change, I hope that is more evident what the following code does:
```cpp
quantity q = delta<K>(300);
quantity_point qp = absolute<K>(300);
static_cast(q.in<http://q.in>(deg_C) != qp.in<http://qp.in>(deg_C).quantity_from_zero());
```
How do you feel about it? Aren't the two ways to create a quantity too much?
śr., 19 cze 2024 o 14:27 Mateusz Pusz <mateusz.pusz_at_[hidden]mail.com<mailto:mateusz.pusz_at_[hidden]>> napisał(a):
I've just implemented something like this in this PR: https://github.com/mpusz/mp-units/pull/585. Please let me know if you think that is a good idea that solves the problem raised by Tiago (accidental error-prone syntax for temperatures). If so, I will merge it with the library and update the paper in the next revision.
Best
Mat
śr., 19 cze 2024 o 17:30 Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>> napisał(a):
The `relative` and `absolute` modifiers will be stripped upon construction, so the resulting quantity and quantity_point types will just use the underlying unit in its instantiation.
śr., 19 cze 2024 o 17:29 Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>> napisał(a):
I have an alternative proposal.
Let's consider adding `alternative(Reference)` and `relative(Reference)` modifiers that will influence how:
- multiply syntax works
- limit invalid use cases for quantity and quantity_point.
Here are the main points of this new design:
1. All references/units that do not specify point origin (are not offset units) would be considered `relative` by default. This means that `42 * m` will create a `quantity` and would be the same as calling `42 * relative(m)`.
2. Multiply syntax could be extended to allow quantity_point creation with the `42 * absolute(m)` syntax. This will provide an implicit zeroth point origin.
3. For units that specify a point origin (kelvin, degree_Celsius, and degree_Fahrenheit), the user would always need to specify a modifier. This means that:
- `4 * deg_C` does not compile
- `4 * relative(deg_C)` creates a `quantity`
- `4 * absolute(deg_C)` creates a `quantity_point`
4. Constrain constructors of quantity or quantity_point to require the same:
quantity q1(4, m); // OK
quantity q2(4, relative(m)); // OK
quantity q3(4, absolute(m)); // Compile-time error
quantity_point qp1(4, m); // OK
quantity_point qp2(4, relative(m)); // Compile-time error
quantity_point qp3(4, absolute(m)); // OK
quantity q4(4, deg_C); // Compile-time error
quantity q5(4, relative(deg_C)); // OK
quantity q6(4, absolute(deg_C)); // Compile-time error
quantity_point qp4(4, deg_C); // Compile-time error
quantity_point qp5(4, relative(deg_C)); // Compile-time error
quantity_point qp6(4, absolute(deg_C)); // OK
Please note the above would also apply to Kelvin and Fahrenheit.
Does it solve the issue discussed here?
śr., 19 cze 2024 o 16:07 Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>> napisał(a):
Predefining instances of quantity and quantity_point have some issues:
1. We have to pick a representation type that will suit all the users.
2. We can't pass such instances to .in() member function.
3. It might be hard to spell the type of a class template in the interface.
4. We might have issues in using a hierarchy of strong quantity types for temperatures (users should be allowed to "inherit" and easily use their own more specialized temperatures from the quantity_spec provided in the library)
śr., 19 cze 2024 o 15:43 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> napisał(a):
deg_F could be a quantity_point instance
and
rel_deg_F a quantity instance
-----Ursprüngliche Nachricht-----
Von: Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>>
Gesendet: Mi 19.06.2024 15:34
Betreff: Re: [std-proposals] On the standardization of mp-units P3045R1
An: std-proposals_at_lists.isocpp.org<mailto:std-proposals_at_[hidden]>;
CC: Sebastian Wittmeier <wittmeier_at_[hidden]<mailto:wittmeier_at_[hidden]>>;
But are those two objects/variables of the same type, so they have the same behavior?
śr., 19 cze 2024 o 15:31 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> napisał(a):
Two units? deg_F and rel_deg_F
only rel_deg_F can be used for multiplication
so
gp.in<http://gp.in>(deg_F).quantity_from_zero() is possible
and
auto t60 = 60 * rel_deg_F
is needed
-----Ursprüngliche Nachricht-----
Von: Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>>
Gesendet: Mi 19.06.2024 13:45
Betreff: Re: [std-proposals] On the standardization of mp-units P3045R1
An: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>;
CC: Sebastian Wittmeier <wittmeier_at_projectalpha.org<mailto:wittmeier_at_[hidden]>>;
While writing the answer to Ville, I realized that there is one more issue. We will have to write:
quantity_point qp(20 * rel_deg_C);
std::cout << qp.in<http://qp.in>(rel_deg_F).quantity_from_zero();
Which might be confusing for scaling quantity_point. Also, we will need to add `rel_` to Kelvins and all its prefixes for the same reason as in the other email.
śr., 19 cze 2024 o 13:26 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> napisał(a):
For the specific heat capacity, rel_deg_C is correct anyway, as it is not related to the absolute temperature, is it?
For the ideal gas law, R, however, is more problematic:
auto R = 8.314 * N * m / (rel_deg_C * mol)
All or all except one unit have to be quantity points. But they are all quantities.
But one cannot (with the current library) calculate with quantity points.
That is an error, which was in mp-units before.
I find it less problematic at the formulas than when defining the input value, because beginners would rather define values than formulas. Formulas are hopefully tested at least with one set of values.
And if an absolute temperature is provided as an input with type quantity point then the code for the formula has to deal with it by converting back to a relative temperature (e.g. relative to T0)..
-----Ursprüngliche Nachricht-----
Von: Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>>
Gesendet: Mi 19.06.2024 13:01
Betreff: Re: [std-proposals] On the standardization of mp-units P3045R1
An: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>;
CC: Sebastian Wittmeier <wittmeier_at_[hidden]<mailto:wittmeier_at_[hidden]>>;
Hi Sebastian,
You are right, and that is actually a really good idea! :-)
Sure, we can do that.
The only downside I see is that we will have to write something like the below for the specific heat capacity or similar units:
quantity<J / (kg * rel_deg_C)> specific_heat_capacity = 42 * J / (kg * rel_deg_C);
śr., 19 cze 2024 o 12:24 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> napisał(a):
Hi Mateusz,
If I understand correctly, the library introduces types and objects for the units of the same name.
If one makes an exception from this rule for °C:
- The type is called `deg_C`
- The object is called `rel_deg_C`
- (+ the same for Fahrenheit)
Then
auto t20 = (20 * rel_deg_C)
is a quantity of 20°C temperature difference and of type `quantity<deg_C, int>`
auto at20a = quantity_point qp1(t20)
or
auto at20b = zeroth_degree_Celsius + t20
are quantity points of 20°C absolute temperature and of type quantity_point<deg_C, ice_point, int>
Then we do not need 2 units or 2 types
As far as I understand the same name was used for simplicity and better compiler error messages, should still be similar enough and clear enough
The internal type makes sense both for quantity and quantity point
We keep full genericity and no actual special casing for temperature
-----Ursprüngliche Nachricht-----
Von: Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>>
Gesendet: Mi 19.06.2024 08:35
Betreff: Re: [std-proposals] On the standardization of mp-units P3045R1
An: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>;
CC: Sebastian Wittmeier <wittmeier_at_projectalpha.org<mailto:wittmeier_at_[hidden]>>;
Unfortunately, there are some other issues here as well. If we introduce two independent units like rel_deg_C and abs_deg_C we will have to make them somehow aware of each other and support this in the framework. Let's see the following code:
quantity_point qp1(20 * rel_deg_C); // should instantiate quantity_point<abs_deg_C, ice_point, int>
quantity_point qp2(15 * rel_deg_C); // should instantiate quantity_point<abs_deg_C, ice_point, int>
quantity q = qp1 - qp2; // should instantiate quantity<rel_deg_C, int>
wt., 18 cze 2024 o 21:44 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> napisał(a):
Ok, than really use two units: rel_deg_C and abs_deg_C.
quantity_point(...).in(abs_deg_C) would be accepted
quantity_point(...).in(rel_deg_C) would not
So no longer confusing.
Similar for all other usages: The one making sense works.
The one not making sense is not accepted.
Why special-case temperature compared to other units?
============================================
temperatures are used very often as quantity point,
the quantity point has a general physical meaning (as the reference is defined),
and the reference point is != 0 (at least for °C and °F unlike K).
What about generic code?
====================
Generic code should be able to access quantity and quantity point in an identical (but possibly more verbose) way for all units, temperature and others
What about possible other units similar to temperature?
============================================
Perhaps the library should allow this same special-casing for user-defined units, too.
-----Ursprüngliche Nachricht-----
Von: Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>>
Gesendet: Di 18.06.2024 16:56
Betreff: Re: [std-proposals] On the standardization of mp-units P3045R1
An: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>;
CC: Sebastian Wittmeier <wittmeier_at_[hidden]<mailto:wittmeier_at_[hidden]>>;
Unfortunately, this is not that easy. Let's see this example:
quantity_point temp(300. * K);
std::cout << temp.in<http://temp.in>(deg_C).quantity_from_zero() << " " << temp.in<http://temp.in>(deg_F).quantity_from_zero() << "\n";
This prints:
26.85 °C 80.33 °F
Using `rel_deg_C` and `rel_deg_F` would be confusing here.
Best
Mat
wt., 18 cze 2024 o 16:49 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> napisał(a):
Then just change deg_C to rel_deg_C to prevent misuse
so
23 * rel_deg_C
would work for a temperature difference and
quantity_point(28.0 * rel_deg_C)
would be needed for the absolute temperature of 301K.
One can always later on define a nicer-looking shortcut for the second one.
-----Ursprüngliche Nachricht-----
Von: Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>>
Gesendet: Di 18.06.2024 16:37
Betreff: Re: [std-proposals] On the standardization of mp-units P3045R1
An: std-proposals_at_[hidden]<mailto:std-proposals_at_lists.isocpp.org>;
CC: Sebastian Wittmeier <wittmeier_at_projectalpha.org<mailto:wittmeier_at_[hidden]>>;
`deg_C` is just a symbol for the `si::degree_Celsius` unit. We could consider not providing Celsius and Fahrenheit units at all, but this would make many users unhappy. Degree Celsius is one of the official SI units (https://en.wikipedia.org/wiki/International_System_of_Units#Derived_units), and not providing support for it would be problematic.
The affine space abstraction is the best solution for the temperature problem according to our knowledge and experience:
- when we state that today is 4 degree Celsius warmer than yesterday we mean the `quantity`
- when we state that today temperature is 23 degree Celsius we mean the `quantity_point`
To prevent errors and to be consistent with maths, quantity_point does not multiply and divide with other units. We can only add or subtract an offset from it or subtract another point to get a quantity.
Multiply syntax (e.g., 23 * deg_C) always results in a quantity and not a quantity_point.
For the sake of correctness, we could add a dirty hack to the generic framework that would disable the multiply syntax for temperatures only. With this, the user would always have to write something like this:
quantity_point temperature(quantity(28.0, deg_C)); // zeroth_degree_Celsius point origin provided by default here
quantity temperature_delta(3.0, deg_C);
But I am not sure if this would be better.
Best
Mat
wt., 18 cze 2024 o 16:18 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> napisał(a):
Hi Mateusz,
how about the (in one of the messages by me today) suggested
rel_deg_C is a quantity
vs.
abs_deg_C is a quantity_point
?
That would prevent bugs, which are easy to introduce for temperature by making that distinction explicit.
Or alternative spellings: deg_rel_C / deg_C_rel
-----Ursprüngliche Nachricht-----
Von: Mateusz Pusz via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Gesendet: Di 18.06.2024 15:54
Betreff: Re: [std-proposals] On the standardization of mp-units P3045R1
An: std-proposals_at_[hidden]rg<mailto:std-proposals_at_[hidden]>;
CC: Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>>; Chip Hogg <chogg_at_[hidden]<mailto:chogg_at_[hidden]>>; Johel Ernesto Guerrero Peña <johelegp_at_[hidden]<mailto:johelegp_at_[hidden]>>; Anthony Williams <anthony_at_[hidden]<mailto:anthony_at_[hidden]>>;
Hi,
Tiago, some time has passed since your last complaint about the same problem. We invited you to our internal meeting, listened to your concerns, and discussed how we can improve here. As you know, the answer was not found at the meeting. Additionally, you stated that you don't want to work to contribute to our proposal and repository and that you will come back with a better interface soon. More info can be found here: https://github.com/mpusz/mp-units/discussions/552. Did you manage to find a better solution to this problem? If so we are open to rediscuss your solution whenever you are ready.
For all other participants of this mailing list, here is a correct solution:
#include <mp-units/ostream.h>
#include <mp-units/systems/si.h>
#include <iostream>
using namespace mp_units;
inline constexpr struct atmospheric_pressure final : named_unit<"atm", mag<101'325> * si::pascal> {} atmospheric_pressure;
int main()
{
using namespace mp_units::si::unit_symbols;
quantity Volume = 1.0 * m3;
quantity_point Temperature(28.0 * deg_C);
quantity n_ = 0.04401 * kg / mol;
quantity R_boltzman = 8.314 * N * m / (K * mol);
quantity mass = 40.0 * kg;
quantity Pressure = R_boltzman * Temperature.in(K).quantity_from_zero() * mass / n_ / Volume;
std::cout << Pressure.in(Pa) << "(" << Pressure.in(atmospheric_pressure) << ")\n";
}
https://godbolt.org/z/E8bf51hKG
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.
Best
Mat
wt., 18 cze 2024 o 15:30 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> napisał(a):
How about the following scales? Are they also an issue?
- Time (Calendar) relative to either anno domini or Unix time?
- Position Coordinate relative to Greenwich?
- Electric Potential relative to earth potential?
- pH, pKa, pKb scales relative to a neutrality of 7?
- Decibels, phon and sone relative to threshold of human hearing?
- Pressure (hydraulic or blood) relative to atmospheric pressure?
- Altitude relative to sea level?
-> For pressure and altitude there are lots of other scales, e.g. used in aviation
- Richter scale relative to detectable earthquakes?
- Beaufort relative to calm wind instead of zero wind?
- Borg physical exertion not starting at zero?
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]ocpp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
wt., 18 cze 2024 o 15:44 Tiago Freire via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> napisał(a):
I understand what the problem is, that is why I’m bringing it forward.
My concerned is that I haven’t written any code that anyone wouldn’t have written and got the wrong answer.
> An absolute value in the paper is a quantity_point, a possibly relative value is a quantity.
Which is a perspective, not convinced that it is the right thing. But That also poses the question, volume is also an absolute value, so is the mass, pressure, etc..
Which means that the right way to write it would be this:
```
quantity_point Volume {1.0 * m*m*m};
quantity_point Temperature {si::ice_point + 28.0 * deg_C};
quantity_point n_{0.04401 * kg / mol};
quantity R_boltzman = 8.314 * N * m / (K * mol);
quantity_point mass {40.0 * kg};
quantity_point P = R_boltzman * Temperature * mass / n_ / Volume;
std::cout << Pressure << std::endl;
```
But this doesn’t compile because quantity_point can’t math.
In order to get it to compile you would have to do this instead:
```
quantity_point Pressure = quantity_point{0.0*Pa} + R_boltzman * (Temperature - mp_units::si::absolute_zero) * (mass - quantity_point{0.0*kg}) / (n_ - quantity_point{0.0*kg / mol}) / (Volume - quantity_point{0.0* m*m*m});
```
Which doesn’t even module the problem properly because the values in PV=nRT are supposed to be absolute values, not deltas.
Hence it raises the question, doing what it seems obvious is the wrong thing (thus questionably safe), and doing the right thing is kind of hard (thus questionably user-friendly). But that what is expected as the correct way to use it.
From: Std-Proposals <std-proposals-bounces_at_[hidden]<mailto:std-proposals-bounces_at_[hidden]>> On Behalf Of Sebastian Wittmeier via Std-Proposals
Sent: Tuesday, June 18, 2024 15:03
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]<mailto:wittmeier_at_[hidden]>>
Subject: Re: [std-proposals] On the standardization of mp-units P3045R1
You are specifically talking about
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3045r1.html#potential-surprises-while-working-with-temperatures
Discussing the difficulty, when to use a difference in temperature or an absolute temperature.
An absolute value in the paper is a quantity_point, a possibly relative value is a quantity.
If I understand correctly, in the current paper to initialize and use absolute temperatures
quantity_point qp2 = (isq::Celsius_temperature(28.0 * deg_C)).in(K)
and
qp2.quantity_from_zero()
would have to be used instead of
quantity Temperature = (28.0 * deg_C).in(K);
The paper also says
"We have added the Celsius temperature quantity type for completeness and to gain more experience with it. Still, maybe a good decision would be to skip it in the standardization process not to confuse users."
-----Ursprüngliche Nachricht-----
Von: Sebastian Wittmeier <wittmeier_at_projectalpha.org<mailto:wittmeier_at_[hidden]>>
Gesendet: Di 18.06.2024 14:42
Betreff: AW: [std-proposals] On the standardization of mp-units P3045R1
An: std-proposals_at_lists.isocpp.org<mailto:std-proposals_at_[hidden]>;
Hi Tiago,
where does this difference of 11x come from?
The temperature with 28°C vs. 301K?
-----Ursprüngliche Nachricht-----
Von: Tiago Freire via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Gesendet: Di 18.06.2024 14:28
Betreff: [std-proposals] On the standardization of mp-units P3045R1
An: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>;
CC: Tiago Freire <tmiguelf_at_hotmail.com<mailto:tmiguelf_at_[hidden]>>;
Hi, I will be participating in St. Louis.
And one of the papers that interested me was P3045R1, unfortunately I may or may not be on time to participate in this particular session.
There’s this question that I would like an answer too, and I wonder if there is anyone who will be attending St. Louis who would be willing to make this question on my behalf:
A lab worker puts in 40Kg of dry ice into a 1 cubic meter pressure tank rated for 10atm, they then vacuum the tank and seal it.
As the CO2 warms up to room temperature (which at a specific date was 28°C) it evaporates, and eventually following the ideal gas law:
PV=nRT
Is this setup dangerous?
Using mp-units (with the exact same design as the one being proposed for standardization) to solve this problem:
```
quantity Volume = 1.0 * m*m*m;
quantity Temperature = (28.0 * deg_C).in(K);
quantity n_ = 0.04401 * kg / mol;
quantity R_boltzman = 8.314 * N * m / (K * mol);
quantity mass = 40.0 * kg;
quantity Pressure = R_boltzman * Temperature * mass / n_ / Volume;
std::cout << Pressure << std::endl;
```
We get the following result:
`211581 N/m2`
(=211.581kPa = 2,09 atm)
But the correct answer is actually: 2275.629kPa = 22.5 atm
(11 time s higher than what mp-units calculated)
How is this considered a design feature and not a bug? (note that other similar libraries don’t have this problem)
And how do the authors think this design choice impacts on safety and user-friendliness?
Thanks.
-- Std-Proposals mailing list Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
-- Std-Proposals mailing list Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]pp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-06-27 08:43:48