On 03/02/2023 20.36, Barry Revzin wrote:
> As I've noted in the past, I have no experience or domain knowledge in anything related to encodings or any of these issues. I'm happy to defer to whatever SG16 says is the right thing.

I don't think SG16 knows what the right thing is;
all we know is that it's a non-trivial topic.
Note that WG21 subgroups, in general, review proposals,
and don't write them for you. (Some SGs might be different.)

> However, Tom's suggestion that we only use charN_t types doesn't work I think. std::format() returns a std::string so once we widen support for messages from simply string literals (and we extend std::format to work in constexpr), static_assert(cond, std::format("error")) needs to be valid.

Note that we cautiously removed requirements in the existing Working Draft a little while
back that the string-literal of a static_assert must, somehow, appear as part of the
diagnostic message. Exactly because it was unclear how exactly that could be achieved
in various situations.

I do notice that we could enhance std::format such that

std::format(u8"bad value {}", i)

yields a std::u8string (currently, I think std::format doesn't take char8_t
format strings at all), so we would need to teach people to write

  static_assert(i > 0, std::format(u8"bad value {}", i));

instead of the variant without "u8". That would relieve a few problems
around representing the message (or at least the format string) in the
literal encoding. And presumably we could then cavalierly defer to
"Unicode rules the world" and just ask implementations to somehow
represent Unicode in the diagnostic messages on a best-effort basis.

Jens