Date: Fri, 28 Jun 2024 20:07:11 +0200
On 28/06/2024 18.34, Tom Honermann via SG16 wrote:
> Thank you, Victor. I will get this scheduled for an upcoming SG16 meeting. I agree it is important that we resolve this quickly.
I've assigned
P3068 Allowing exception throwing in constant-evaluation
to SG16.
https://github.com/cplusplus/papers/issues/1754
Jens
> 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
>>
>
> Thank you, Victor. I will get this scheduled for an upcoming SG16 meeting. I agree it is important that we resolve this quickly.
I've assigned
P3068 Allowing exception throwing in constant-evaluation
to SG16.
https://github.com/cplusplus/papers/issues/1754
Jens
> 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
>>
>
Received on 2024-06-28 18:07:18