Date: Wed, 2 Sep 2020 09:33:27 +0000
Hi all,
We allow Unicode identifiers (if/when P1949 is adopted, UAX31 identifiers). Implementations will therefore need to have a mechanism for communicating those identifiers to the user via their diagnostics. Let us assume that such mechanism exists as a necessary implementation detail of any reasonable C++ implementation.
By the point at which static_assert() is evaluated, its string argument will have already been converted to its associated implementation-defined literal encoding. For some implementations, this may be a lossy conversion.
I am wary of mandating specific handling of this in the standard because the way in which diagnostics are communicated to the user seems to be something that really should be a quality of implementation issue.
If we were to adjust the standard, then the adjustment should not preclude constexpr computation of the static_assert message, in anticipation of reflection making it possible to format type names into it with constexpr std::format.
static_assert(std::is_base_of_v<MyBase, Arg>,
std::format("Cannot my_cast to {} because {} is not derived from MyBase",
/* reflection expressions here */));
We must not confuse 2 separate concerns:
1. Whether implementations correctly process strings from their internal representation for display in diagnostic messages
2. Whether implementations correctly handle situations in which the literal encoding and the encoding required for displaying diagnostic messages is different.
I am strongly opposed to a solution that restricts static_assert() messages to the basic source character set.
Best regards,
Peter
From: SG16 <sg16-bounces_at_[hidden]> On Behalf Of Martinho Fernandes via SG16
Sent: 01 September 2020 18:16
To: sg16_at_[hidden]
Cc: Martinho Fernandes <rmf_at_[hidden]om>
Subject: Re: [SG16] On the character encoding of diagnostic text
EXTERNAL MAIL
On Tue, Sep 1, 2020 at 7:05 PM Aaron Ballman via SG16 <sg16_at_[hidden]<mailto:sg16_at_[hidden]>> wrote:
On Tue, Sep 1, 2020 at 12:08 PM Alisdair Meredith via SG16
<sg16_at_lists.isocpp.org<mailto:sg16_at_[hidden]>> wrote:
>
> For a cross compiler, the basic execution character set should correspond to the target platform, but the diagnostics character set should be for the host?
That matches my understanding.
I suppose a question I could add is whether anyone would like to see a
new character set introduced for diagnostics. My intuition is that it
would be a pretty heavy hammer to bring to bear and that the basic
source character set is probably Good Enough (tm).
Wouldn't these diagnostics be the place people are more likely to use non-basic source characters, though? When it comes to identifiers people will sometimes compromise and restrict themselves and e.g. avoid diacritics, but in error messages I feel like it makes a lot more sense to want to write with the full expression of their native script.
We allow Unicode identifiers (if/when P1949 is adopted, UAX31 identifiers). Implementations will therefore need to have a mechanism for communicating those identifiers to the user via their diagnostics. Let us assume that such mechanism exists as a necessary implementation detail of any reasonable C++ implementation.
By the point at which static_assert() is evaluated, its string argument will have already been converted to its associated implementation-defined literal encoding. For some implementations, this may be a lossy conversion.
I am wary of mandating specific handling of this in the standard because the way in which diagnostics are communicated to the user seems to be something that really should be a quality of implementation issue.
If we were to adjust the standard, then the adjustment should not preclude constexpr computation of the static_assert message, in anticipation of reflection making it possible to format type names into it with constexpr std::format.
static_assert(std::is_base_of_v<MyBase, Arg>,
std::format("Cannot my_cast to {} because {} is not derived from MyBase",
/* reflection expressions here */));
We must not confuse 2 separate concerns:
1. Whether implementations correctly process strings from their internal representation for display in diagnostic messages
2. Whether implementations correctly handle situations in which the literal encoding and the encoding required for displaying diagnostic messages is different.
I am strongly opposed to a solution that restricts static_assert() messages to the basic source character set.
Best regards,
Peter
From: SG16 <sg16-bounces_at_[hidden]> On Behalf Of Martinho Fernandes via SG16
Sent: 01 September 2020 18:16
To: sg16_at_[hidden]
Cc: Martinho Fernandes <rmf_at_[hidden]om>
Subject: Re: [SG16] On the character encoding of diagnostic text
EXTERNAL MAIL
On Tue, Sep 1, 2020 at 7:05 PM Aaron Ballman via SG16 <sg16_at_[hidden]<mailto:sg16_at_[hidden]>> wrote:
On Tue, Sep 1, 2020 at 12:08 PM Alisdair Meredith via SG16
<sg16_at_lists.isocpp.org<mailto:sg16_at_[hidden]>> wrote:
>
> For a cross compiler, the basic execution character set should correspond to the target platform, but the diagnostics character set should be for the host?
That matches my understanding.
I suppose a question I could add is whether anyone would like to see a
new character set introduced for diagnostics. My intuition is that it
would be a pretty heavy hammer to bring to bear and that the basic
source character set is probably Good Enough (tm).
Wouldn't these diagnostics be the place people are more likely to use non-basic source characters, though? When it comes to identifiers people will sometimes compromise and restrict themselves and e.g. avoid diacritics, but in error messages I feel like it makes a lot more sense to want to write with the full expression of their native script.
Received on 2020-09-02 04:37:02