Date: Fri, 25 Oct 2024 09:03:47 +0200
One more question. It seems that we can define the same Unicode thing in
many ways:
inline constexpr struct pi final : mag_constant<symbol_text{u8"π", "pi"},
std::numbers::pi_v<long double>> {} pi;
inline constexpr struct pi final : mag_constant<symbol_text{u8"\u03c0", "pi"},
std::numbers::pi_v<long double>> {} pi;
inline constexpr struct pi final : mag_constant<symbol_text{u8"\N{GREEK
SMALL LETTER PI}", "pi"}, std::numbers::pi_v<long double>> {} pi;
We agreed that the first spelling is not the best choice. The second is
already used to define chrono duration I/O (
https://eel.is/c++draft/time.duration.io). However, maybe the third line
provides the most information about what is going on?
What is your opinion here?
Best
Mat
I thi
czw., 24 paź 2024 o 23:09 Mateusz Pusz <mateusz.pusz_at_[hidden]> napisał(a):
> > Format strings are parsed at compile time, I thought, so this
> > could be a compile-time error?
>
> Sure, assuming compile-time format string validation. For runtime we will
> get exception which is consistent with how other formatters raise an error.
>
> > I don't know whom you address with "we".
>
> By "we" I meant the SG16. I wanted to ensure that this is what this group
> would like to see in the wording for Unicode identifiers.
>
> Of course, the LWG might want to change it later on in the process, but I
> need to start with something and this looks like a good starting point you
> me. Thanks Jens!
>
> Best
>
> Mat
>
>
>
>
> czw., 24 paź 2024, 22:58 użytkownik Jens Maurer <jens.maurer_at_[hidden]>
> napisał:
>
>>
>>
>> On 24/10/2024 07.46, Mateusz Pusz wrote:
>> >> Could you give an indication of the respective use-case?
>> >
>> > Here is an example for subscript and multiplication sign:
>> >
>> > static_assert(unit_symbol(mag_ratio<1, 18000> * metre / second) ==
>> "[1/18 × 10⁻³ m]/s");
>> > static_assert(unit_symbol<usf{.encoding = portable}>(mag_ratio<1,
>> 18000> * metre / second) == "[1/18 x 10^-3 m]/s");
>>
>> Thanks.
>>
>> >> Could you give a sample std::format invocation where this would happen?
>> >> In particular, I'm opposed to throwing an exception if the value of a
>> >> format argument (not the format string) happens to be a little off.
>> >
>> > Formatting of a dot (⋅) can be found at
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3045r3.html#unit-formatting
>> <
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3045r3.html#unit-formatting
>> >.
>> > The exception is thrown because of a problem in a format string.
>> Someone requested portable output and a dot as a separator.
>>
>> Format strings are parsed at compile time, I thought, so this
>> could be a compile-time error?
>>
>> >> inline constexpr auto π /* U+03C0 GREEK SMALL LETTER PI */ = pi;
>> >
>> > Thanks. I think the second option is a better option, as a user can
>> directly copy-paste glyphs into the code. Do we agree that it is how it
>> should appear in the wording?
>>
>> I don't know whom you address with "we". First, a little chat on the
>> reflector is not a good venue to establish meaningful consensus for the
>> WG21 process. Second, SG16 is not the appropriate forum to decide on
>> wording. LWG does that. If LWG doesn't agree with the wording, they
>> can ask for a change, but at the very least all information *they*
>> need to know about the funny character is present with the style above.
>>
>> Jens
>>
>>
many ways:
inline constexpr struct pi final : mag_constant<symbol_text{u8"π", "pi"},
std::numbers::pi_v<long double>> {} pi;
inline constexpr struct pi final : mag_constant<symbol_text{u8"\u03c0", "pi"},
std::numbers::pi_v<long double>> {} pi;
inline constexpr struct pi final : mag_constant<symbol_text{u8"\N{GREEK
SMALL LETTER PI}", "pi"}, std::numbers::pi_v<long double>> {} pi;
We agreed that the first spelling is not the best choice. The second is
already used to define chrono duration I/O (
https://eel.is/c++draft/time.duration.io). However, maybe the third line
provides the most information about what is going on?
What is your opinion here?
Best
Mat
I thi
czw., 24 paź 2024 o 23:09 Mateusz Pusz <mateusz.pusz_at_[hidden]> napisał(a):
> > Format strings are parsed at compile time, I thought, so this
> > could be a compile-time error?
>
> Sure, assuming compile-time format string validation. For runtime we will
> get exception which is consistent with how other formatters raise an error.
>
> > I don't know whom you address with "we".
>
> By "we" I meant the SG16. I wanted to ensure that this is what this group
> would like to see in the wording for Unicode identifiers.
>
> Of course, the LWG might want to change it later on in the process, but I
> need to start with something and this looks like a good starting point you
> me. Thanks Jens!
>
> Best
>
> Mat
>
>
>
>
> czw., 24 paź 2024, 22:58 użytkownik Jens Maurer <jens.maurer_at_[hidden]>
> napisał:
>
>>
>>
>> On 24/10/2024 07.46, Mateusz Pusz wrote:
>> >> Could you give an indication of the respective use-case?
>> >
>> > Here is an example for subscript and multiplication sign:
>> >
>> > static_assert(unit_symbol(mag_ratio<1, 18000> * metre / second) ==
>> "[1/18 × 10⁻³ m]/s");
>> > static_assert(unit_symbol<usf{.encoding = portable}>(mag_ratio<1,
>> 18000> * metre / second) == "[1/18 x 10^-3 m]/s");
>>
>> Thanks.
>>
>> >> Could you give a sample std::format invocation where this would happen?
>> >> In particular, I'm opposed to throwing an exception if the value of a
>> >> format argument (not the format string) happens to be a little off.
>> >
>> > Formatting of a dot (⋅) can be found at
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3045r3.html#unit-formatting
>> <
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3045r3.html#unit-formatting
>> >.
>> > The exception is thrown because of a problem in a format string.
>> Someone requested portable output and a dot as a separator.
>>
>> Format strings are parsed at compile time, I thought, so this
>> could be a compile-time error?
>>
>> >> inline constexpr auto π /* U+03C0 GREEK SMALL LETTER PI */ = pi;
>> >
>> > Thanks. I think the second option is a better option, as a user can
>> directly copy-paste glyphs into the code. Do we agree that it is how it
>> should appear in the wording?
>>
>> I don't know whom you address with "we". First, a little chat on the
>> reflector is not a good venue to establish meaningful consensus for the
>> WG21 process. Second, SG16 is not the appropriate forum to decide on
>> wording. LWG does that. If LWG doesn't agree with the wording, they
>> can ask for a change, but at the very least all information *they*
>> need to know about the funny character is present with the style above.
>>
>> Jens
>>
>>
Received on 2024-10-25 07:04:02