Hey folks.
STATICALLY-WIDEN 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 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.
---
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!