If I recall correctly, there was a suggestion that delimiters be restricted
to the basic character set. I don't think that's quite the right approach,
although it would work. It would work because the basic character set is
single byte encoded, and therefore the assigned meaning of the encoded byte
is almost irrelevant for purposes of matching. The core problem is, of
course, that we don't have a way of determining the literal encoding (yet)
in a fashion that would allow the core constant expression to be parsed
according to that encoding, and we certainly don't have any mechanism for
run-time strings used by vformat. Except locale, and, let's not.

I don't believe the standard supports u{8,16.32} string views for
conversion to a format string, at least not yet?

I think we need to look for a way to say that the delimiter character is
not multi-byte encoded?

On Fri, Nov 26, 2021 at 4:50 PM Inbal Levi via SG16 <sg16_at_[hidden]>
wrote:

> Great, thanks!
>
> Highly appreciated.
> Inbal
>
> On Fri, 26 Nov 2021 at 22:34, Tom Honermann <tom_at_[hidden]> wrote:
>
>> Thank you, Inbal. Yes, I’ll put this on the agenda for our 2021-12-01
>> telecon this coming Wednesday.
>>
>> Tom.
>>
>> On Nov 26, 2021, at 12:04 PM, Inbal Levi <sinbal2l_at_[hidden]> wrote:
>>
>> 
>> Hello SG16,
>> LEWG have recently seen "P2286R3
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2286r3.html>: Formatting
>> Ranges".
>> In R3 there's a suggestion to have the delimiter user defined, and as
>> Billy wrote:
>> Based on discussions of basic character set versus Unicode for
>> delimiters, a review from SG16 (Text processing) is needed before
>> additional review in Library Evolution.
>>
>> Could you please review the solution and its details as soon as possible?
>> We would love to be able to see it again on LEWG in the near future.
>>
>> Thank you in advance,
>> Inbal Levi
>>
>> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>