I think we should either solve this problem in P3068 or take the relevant library changes out (keeping language changes) and address them in a separate paper. I also don't want to block the language feature.

- Victor

On Fri, Jun 28, 2024 at 8:56 AM Hana Dusíková <hanicka@hanicka.net> wrote:
I'm happy to help here, but I hope this won't somehow block the exceptions. I'm making everything in exception types including `exception::what() override` constexpr and implementation can choose to access information out of it to provide better error message. But in the paper there is no such wording mandating it. 

Do you want to solve the problem you are talking about as part of this paper or somehow else?

Hana

On 28. 6. 2024, at 16:34, Victor Zverovich <victor.zverovich@gmail.com> 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 "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 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