On Mon, Sep 7, 2020 at 10:58 AM JF Bastien <cxx_at_[hidden]> wrote:
>
> Looks good. Minor suggestion:
>
> > Otherwise, the constraint is violated and the implementation shall produce a diagnostic message that includes the text of the string literal, if present.
>
> The “shall” is important here because it’s about “you shall diagnose”, but I think you could have a “should” after to legislate on content. Say:
>
> > shall produce a diagnostic message which should includes the text

Good suggestion, I've applied it locally. Thanks!

~Aaron

>
>
> On Mon, Sep 7, 2020 at 7:14 AM Aaron Ballman <aaron_at_[hidden]> wrote:
>>
>> On Thu, Sep 3, 2020 at 10:41 PM Tom Honermann <tom_at_[hidden]> wrote:
>>
>> >
>>
>> > On 9/3/20 6:59 PM, JF Bastien wrote:
>>
>> >
>>
>> > On Thu, Sep 3, 2020 at 3:36 PM Tom Honermann via SG16 <sg16_at_[hidden]> wrote:
>>
>> >>
>>
>> >> On 9/2/20 5:33 AM, Peter Brett via SG16 wrote:
>>
>> >>
>>
>> >> 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:
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> Whether implementations correctly process strings from their internal representation for display in diagnostic messages
>>
>> >> 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.
>>
>> >>
>>
>> >> I would also be strongly opposed to a solution that prohibits characters outside of the basic source character set, but I think it would be reasonable to specify that characters outside the basic source character set may be subject to substitution (potentially lossy), presentation in non-glyph form (as a UCN), or perhaps even dropped (mildly opposed). Is that a view point that you could support?
>>
>> >
>>
>> >
>>
>> > I don't think we should specify what happens to the string. Rather we should specify what kind of string literals are accepted (and I'd accept any valid string literal).
>>
>> >
>>
>> > First, what happens to diagnostics is outside the abstract machine, we don't legislate that. Second, it's not the source character set nor is it the execution one. What I mean by this is that the source character set is what the compiler consumes and my editor shows, but diagnostics are what my shell shows (that's not the compiler, nor is it the editor), but it can be in an IDE. Imagine that I run clang in my favorite PDP-11 shell emulator... clang might be nice to check if Unicode is supported and then escape what's not supported, but does the Standard need to say anything? Now imagine I pipe stderr to /dev/null, have I now made my compiler non-conformant? What if I pipe it to a file? I can't see it unless I open the file... is it still conformant? What about diagnostics in an IDE, where I only see diagnostics for the code currently open in the IDE, the others are "hidden". Say the IDE colors the diagnostics, is it still conformant? etc. The Standard doesn't care about any of this, it's not useful for us to care, let's not say anything. Trying to say something is legislating away implementation freedom, let's just trust that implementation aren't adversarial and they're actually trying to help users.
>>
>> >
>>
>> > I agree with all of this, but there does seem to be some genuine interest in improving something here. The question I've posed have been intended to probe those interests.
>>
>> >
>>
>> > For reference, since I don't think it has been pointed out yet, here is the relevant wording from the C++ standard. What changes would make people more happy than the status quo?
>>
>> >
>>
>> > [intro.compliance]p2.2:
>>
>> >
>>
>> > If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
>>
>> >
>>
>> > [dcl.pre]p6:
>>
>> >
>>
>> > In a static_assert-declaration, the constant-expression shall be a contextually converted constant expression of type bool. If the value of the expression when so converted is true, the declaration has no effect. Otherwise, the program is ill-formed, and the resulting diagnostic message ([intro.compliance]) shall include the text of the string-literal, if one is supplied, except that characters not in the basic source character set are not required to appear in the diagnostic message. [Example:
>>
>> > static_assert(sizeof(int) == sizeof(void*), "wrong pointer size");
>>
>> > — end example]
>>
>> >
>>
>> > [dcl.attr.deprecated]p1:
>>
>> >
>>
>> > The attribute-token deprecated can be used to mark names and entities whose use is still allowed, but is discouraged for some reason. [Note: In particular, deprecated is appropriate for names and entities that are deemed obsolescent or unsafe. — end note] It shall appear at most once in each attribute-list. An attribute-argument-clause may be present and, if present, it shall have the form:
>>
>> > ( string-literal )
>>
>> > [Note: The string-literal in the attribute-argument-clause could be used to explain the rationale for deprecation and/or to suggest a replacing entity. — end note]
>>
>> >
>>
>> > [dcl.attr.deprecated]p4:
>>
>> >
>>
>> > Recommended practice: Implementations should use the deprecated attribute to produce a diagnostic message in case the program refers to a name or entity other than to declare it, after a declaration that specifies the attribute. The diagnostic message should include the text provided within the attribute-argument-clause of any deprecated attribute applied to the name or entity.
>>
>> >
>>
>> > [dcl.attr.nodiscard]p4:
>>
>> >
>>
>> > Recommended practice: Appearance of a nodiscard call as a potentially-evaluated discarded-value expression ([expr.prop]) is discouraged unless explicitly cast to void. Implementations should issue a warning in such cases. [Note: This is typically because discarding the return value of a nodiscard call has surprising consequences. — end note] The string-literal in a nodiscard attribute-argument-clause should be used in the message of the warning as the rationale for why the result should not be discarded.
>>
>> >
>>
>> > [cpp.error]p1:
>>
>> >
>>
>> > A preprocessing directive of the form
>>
>> > # error pp-tokensopt new-line
>>
>> > causes the implementation to produce a diagnostic message that includes the specified sequence of preprocessing tokens, and renders the program ill-formed.
>>
>> >
>>
>> > At a minimum, there do appear to be opportunities to improve consistency in wording here. We have an interesting mix of "shall", "should", "could", and ... "causes".
>>
>>
>>
>> With the exception of "causes", I think the words of power are
>>
>> generally correct (in C++). You use "should" in Recommended Practice
>>
>> sections to give normative suggestion and shall in Semantic sections
>>
>> to give normative requirements, which explains the difference between
>>
>> the attributes and the static_assert wording. The C wording had a bit
>>
>> of may/should confusion that I am correcting with my paper for that
>>
>> committee.
>>
>>
>>
>> I've attached an updated (rewritten) version of the paper that goes in
>>
>> the direction I've understood from SG16 so far. I do still have an
>>
>> open question as to whether anyone would like to see #error get some
>>
>> words to roll back to an earlier phase of translation like we do for
>>
>> _Pragma. There is implementation divergence in this space already with
>>
>> an example that may be compelling to some:
>>
>> https://godbolt.org/z/zP44xE
>>
>>
>>
>> ~Aaron
>>
>>
>>
>> >
>>
>> > Tom.
>>
>> >
>>
>> >
>>
>> >
>>
>> >>
>>
>> >> Tom.
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> 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]>
>>
>> >> 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]> wrote:
>>
>> >>
>>
>> >> On Tue, Sep 1, 2020 at 12:08 PM Alisdair Meredith via SG16
>>
>> >> <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.
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> --
>>
>> >> SG16 mailing list
>>
>> >> SG16_at_[hidden]
>>
>> >> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
>> >
>>
>> >
>>