Date: Mon, 28 Oct 2024 16:17:17 -0400
u8"\u03c0" and u8"\N{GREEK SMALL LETTER PI}" produce equivalent results,
but don't provide equivalent information to the reader or reviewer. An
error in the first form is hard to diagnose, and if there were a typo it
would be harder to fix, possibly needing an expert to weigh in. A typo in
the second form would be easy to diagnose and fix editorially. Essentially
the case for why we adopted the \N escapes in the first place.
On Fri, Oct 25, 2024 at 5:25 AM Corentin Jabot via SG16 <
sg16_at_[hidden]> wrote:
>
>
> On Fri, Oct 25, 2024 at 9:04 AM Mateusz Pusz via SG16 <
> sg16_at_[hidden]> wrote:
>
>> 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?
>>
>
> Both are strictly equivalent so LWG/editors can decide what they like best!
>
>
>
>> 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
>>>>
>>>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
but don't provide equivalent information to the reader or reviewer. An
error in the first form is hard to diagnose, and if there were a typo it
would be harder to fix, possibly needing an expert to weigh in. A typo in
the second form would be easy to diagnose and fix editorially. Essentially
the case for why we adopted the \N escapes in the first place.
On Fri, Oct 25, 2024 at 5:25 AM Corentin Jabot via SG16 <
sg16_at_[hidden]> wrote:
>
>
> On Fri, Oct 25, 2024 at 9:04 AM Mateusz Pusz via SG16 <
> sg16_at_[hidden]> wrote:
>
>> 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?
>>
>
> Both are strictly equivalent so LWG/editors can decide what they like best!
>
>
>
>> 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
>>>>
>>>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
Received on 2024-10-28 20:17:32