Date: Thu, 24 Oct 2024 23:09:10 +0200
> 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
>
>
> 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-24 21:09:25