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]> 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]> 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]>
>> *Gesendet:* Mi 19.06.2024 15:34
>> *Betreff:* Re: [std-proposals] On the standardization of mp-units P3045R1
>> *An:* std-proposals_at_[hidden];
>> *CC:* Sebastian Wittmeier <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]> napisał(a):
>>
>> Two units? deg_F and rel_deg_F
>>
>>
>>
>>
>>
>> only rel_deg_F can be used for multiplication
>>
>>
>>
>>
>>
>> so
>>
>> 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]>
>> *Gesendet:* Mi 19.06.2024 13:45
>> *Betreff:* Re: [std-proposals] On the standardization of mp-units P3045R1
>> *An:* std-proposals_at_[hidden];
>> *CC:* Sebastian Wittmeier <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(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]> 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]>
>> *Gesendet:* Mi 19.06.2024 13:01
>> *Betreff:* Re: [std-proposals] On the standardization of mp-units P3045R1
>> *An:* std-proposals_at_[hidden];
>> *CC:* Sebastian Wittmeier <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]> 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]>
>> *Gesendet:* Mi 19.06.2024 08:35
>> *Betreff:* Re: [std-proposals] On the standardization of mp-units P3045R1
>> *An:* std-proposals_at_[hidden];
>> *CC:* Sebastian Wittmeier <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]> 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]>
>> *Gesendet:* Di 18.06.2024 16:56
>> *Betreff:* Re: [std-proposals] On the standardization of mp-units P3045R1
>> *An:* std-proposals_at_[hidden];
>> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
>> Unfortunately, this is not that easy. Let's see this example:
>>
>> quantity_point temp(300. * K);
>> std::cout << temp.in(deg_C).quantity_from_zero() << " " << 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]> 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]>
>> *Gesendet:* Di 18.06.2024 16:37
>> *Betreff:* Re: [std-proposals] On the standardization of mp-units P3045R1
>> *An:* std-proposals_at_[hidden];
>> *CC:* Sebastian Wittmeier <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]> 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]>
>> *Gesendet:* Di 18.06.2024 15:54
>> *Betreff:* Re: [std-proposals] On the standardization of mp-units P3045R1
>> *An:* std-proposals_at_[hidden];
>> *CC:* Mateusz Pusz <mateusz.pusz_at_[hidden]>; Chip Hogg <chogg_at_[hidden]>;
>> Johel Ernesto Guerrero Peña <johelegp_at_[hidden]>; Anthony Williams <
>> 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]> 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]
>> 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]> 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]> *On
>> Behalf Of *Sebastian Wittmeier via Std-Proposals
>> *Sent:* Tuesday, June 18, 2024 15:03
>> *To:* std-proposals_at_[hidden]
>> *Cc:* Sebastian Wittmeier <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_[hidden]>
>> *Gesendet:* Di 18.06.2024 14:42
>> *Betreff:* AW: [std-proposals] On the standardization of mp-units P3045R1
>> *An:* 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]>
>> *Gesendet:* Di 18.06.2024 14:28
>> *Betreff:* [std-proposals] On the standardization of mp-units P3045R1
>> *An:* std-proposals_at_[hidden];
>> *CC:* Tiago Freire <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] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>