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
>