C++ Logo

sg16

Advanced search

Re: [isocpp-sg16] SG16 review of P3068 Allowing exception throwing in constant-evaluation

From: Victor Zverovich <victor.zverovich_at_[hidden]>
Date: Fri, 28 Jun 2024 09:06:44 -0700
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_at_[hidden]> 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_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 16:06:57