Date: Tue, 13 May 2025 09:53:13 +0200
Hey folks.
STATICALLY-WIDEN <https://eel.is/c++draft/time.general#2> is a magic
standard utility that conjures a string literal of a given type.
This is implemented with macros.
As we hopefully add char8_t support to format, we will want STATICALLY-WIDEN
<https://eel.is/c++draft/time.general#2> to also support char8_t.
At some point, this becomes cumbersome.
We could envision that we have constexpr facilities to transcode to the
literal encoding so that we could
implement STATICALLY-WIDEN as
define_static_string(to_literal_encoding(u8""));
However, this might get fairly involved in terms of
specification/implementation efforts (it boils down to making a constexpr
interface over iconv)
But it would be fairly easy for an implementation to support
define_encoded_static_string<char>(u8""); as we already have the machinery
in place to produce different sorts of string literals.
Note that this gets more complicated if we want to accept something other
than u8 as input, as it forces the compiler to be able to convert between
arbitrary encoding, and requires more machinery than what is needed to
implement [lex.string].
The main use case for this is to convert string literals, so only
supporting u8 inputs would not be limiting.
Adapting the wording from P391,
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3491r2.html>
define_encoded_static_string could be specified as
STATICALLY-WIDEN <https://eel.is/c++draft/time.general#2> is a magic
standard utility that conjures a string literal of a given type.
This is implemented with macros.
As we hopefully add char8_t support to format, we will want STATICALLY-WIDEN
<https://eel.is/c++draft/time.general#2> to also support char8_t.
At some point, this becomes cumbersome.
We could envision that we have constexpr facilities to transcode to the
literal encoding so that we could
implement STATICALLY-WIDEN as
define_static_string(to_literal_encoding(u8""));
However, this might get fairly involved in terms of
specification/implementation efforts (it boils down to making a constexpr
interface over iconv)
But it would be fairly easy for an implementation to support
define_encoded_static_string<char>(u8""); as we already have the machinery
in place to produce different sorts of string literals.
Note that this gets more complicated if we want to accept something other
than u8 as input, as it forces the compiler to be able to convert between
arbitrary encoding, and requires more machinery than what is needed to
implement [lex.string].
The main use case for this is to convert string literals, so only
supporting u8 inputs would not be limiting.
Adapting the wording from P391,
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3491r2.html>
define_encoded_static_string could be specified as
--- template <ranges::input_range R, *character-type* CharT> requires same_as<char8_t, ranges::range_value_t<R>> consteval const * define_encoded_static_string(R&& r); The sequence of characters denoted by the sequence of code units in r is encoded to a sequence of code units r' in the associated character encoding of the character type CharT. If a character lacks representation in the associated character encoding, or if r is not a valid UTF-8 code unit sequence, define_encoded_static_string is not a constant expression. Let V be the pack of elements of type CharT in r'. If r is a string literal, then V does not include the trailing null terminator of r. Let P be the template parameter object ([temp.param]) of type const CharT[sizeof...(V)+1] initialized with {V..., CharT()}. Returns: P. ---- Was that considered? Cheers!
Received on 2025-05-13 07:53:34