Thank you, Victor. I will get this scheduled for an upcoming SG16
meeting. I agree it is important that we resolve this quickly.

This might be good impetus for us to more generally solve the problem of
what locale means during constant evaluation. I think we've previously
discussed similar concerns in the context of a future constexpr
std::format(). Can anyone think of existing cases (defects) where the
standard specifies locale dependent behavior in constant context? I
can't recall if any such cases already exist.

Tom.

On 6/28/24 10:34 AM, Victor Zverovich via SG16 wrote:
> Dear Tom and other Unicoders,
>
> I would like to bring your attention to a paper that seems to have
> slipped through the cracks and has not been reviewed by SG16 despite
> having a critical text/encoding aspect to it. This paper is P3068
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3068r2.html> "Allowing
> exception throwing in constant-evaluation".
>
> It looks like a mainly language feature so it's not very
> surprising that we missed it. However, enabling exceptions at compile
> time opens an important question about compile-time exception message
> encoding (and indeed it touches exception::what) which was previously
> moot. It is closely related to LWG4087
> <https://cplusplus.github.io/LWG/issue4087> which we discussed
> recently and I think we are in a unique position to not repeat
> mistakes from decades ago. Instead we can make exception messages
> usable portably at compile time and compatible with other compile-time
> facilities. And even if we don't want to do that, at the very least we
> need to revise the part of the wording that indirectly talks about the
> C locale since it is obviously incorrect at compile time.
>
> I brought up this issue during the review of this paper by LEWG and,
> if I am not mistaken, Eddie voiced his support but unfortunately LEWG
> completely ignored it for some reason. So I suggest that SG16 should
> take initiative and review this before it is too late and the feature
> ships leaving exceptions in an underspecified and not very usable
> state, incompatible with formatting facilities. This issue is so
> severe in my opinion that I voted against forwarding this paper even
> though I am otherwise in favor of the language facility itself.
>
> Cheers,
> Victor
>