Date: Fri, 28 Jun 2024 17:56:42 +0200
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_at_[hidden]> 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
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_at_[hidden]> 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
Received on 2024-06-28 15:56:59