Date: Wed, 19 Oct 2022 15:24:15 -0400
On 10/19/22 6:02 AM, Corentin Jabot via SG16 wrote:
>
>
> On Wed, Oct 19, 2022 at 9:22 AM Peter Brett via SG16
> <sg16_at_[hidden]> wrote:
>
> Hi Tom,
>
> I’ve reviewed the British Standards Institute committee’s draft
> comments and I have not found any which require SG16 review.
>
> I personally have been absolutely snowed under with regular work
> during the whole of the comment period and I haven’t even had the
> opportunity to glance at the committee draft.
>
> Best regards,
>
>
> Hey Peter,
> I'm seeing a comment about new-lines/P2348 in the list of GB comments.
> Given that Core decided against the direction of P2348, SG16 might
> want to revisit that question.
I wasn't aware of CWG having made such a decision. The last CWG
discussion I see for P2348 is
https://wiki.edg.com/bin/view/Wg21telecons2022/Teleconference2022-09-09#D2348R3_Whitespaces_Wording_Reva
from 2022-09-09. That discussion was for a draft R3 revision and ends
with "Corentin redrafting". P2348R3 <https://wg21.link/p2348r3> was
submitted for the September mailing. Does the published revision address
CWG's direction? Or was there a more recent discussion I'm not aware of?
Tom.
> Peter
>
> *From:*SG16 <sg16-bounces_at_[hidden]> *On Behalf Of *Tom
> Honermann via SG16
> *Sent:* 18 October 2022 21:31
> *To:* sg16_at_[hidden]
> *Cc:* Tom Honermann <tom_at_[hidden]>
> *Subject:* Re: [SG16] Agenda for the 2022-10-19 SG16 telecon
>
> This is your friendly reminder that this meeting is taking place
> tomorrow.
>
> The German NB has released a draft of their NB comments. None of
> those require review by SG16. As far as I know, no other NB (other
> than INCITS for the US) has released draft comments yet.
>
> Any polling conducted tomorrow will be for changes relative to the
> status quo (the balloted document for which N4917
> <https://urldefense.com/v3/__https:/wg21.link/n4917__;!!EHscmS1ygiU1lA!BObYHCxLPJ4bb2Cfrzw4knCcZud98cCwcpQF-Iw4t1b4p8zqowXOQr-6K0M7Aqtujj9JmRL1cCuaIPY$>
> is close enough); not relative to other NB comments (which some of
> us may or may not have knowledge of).
>
> Tom.
>
> On 10/14/22 12:20 AM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a telecon on Wednesday, October 19th, at 19:30
> UTC (timezone conversion
> <https://urldefense.com/v3/__https:/www.timeanddate.com/worldclock/converter.html?iso=20221019T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest__;!!EHscmS1ygiU1lA!BObYHCxLPJ4bb2Cfrzw4knCcZud98cCwcpQF-Iw4t1b4p8zqowXOQr-6K0M7Aqtujj9JmRL1ljvU2sY$>).
>
> The agenda is:
>
> * NB comment processing.
>
> The details below are a copy of what was originally included
> with the agenda for the October 12th meeting.
>
> INCITS has made US NB comments available to its members. I
> reviewed the list and identified the following as ones that I
> believe SG16 should establish a position on. There are other
> comments that are related to papers SG16 has previously
> discussed, but in those cases, I believe the concerns raised
> do not require SG16 input.
>
> Due to duplicated comments in the list of US comments, it is
> possible that the comment identifiers below will change.
>
>
> US-2: [defns.multibyte]
> <https://urldefense.com/v3/__http:/eel.is/c**Adraft/defns.multibyte__;Kys!!EHscmS1ygiU1lA!BObYHCxLPJ4bb2Cfrzw4knCcZud98cCwcpQF-Iw4t1b4p8zqowXOQr-6K0M7Aqtujj9JmRL1QFFp2co$>
>
> The notion of an "execution character set" is no longer given
> prominence in the Draft standard, aside from some notes about
> its relationship to the concept as defined by C, and
> clarifying that certain character encodings are unrelated to
> this character set. This makes it a questionable choice for
> use in the definition of "multibyte character".
>
> *Proposed change:*
>
> Change the definition of "multibyte character" to use a
> character encoding with a more definite specification given by
> the Standard.
>
>
> US-38: [format.string.escaped]
> <https://urldefense.com/v3/__https:/eel.is/c**Adraft/format.string.escaped__;Kys!!EHscmS1ygiU1lA!BObYHCxLPJ4bb2Cfrzw4knCcZud98cCwcpQF-Iw4t1b4p8zqowXOQr-6K0M7Aqtujj9JmRL1XoaPMxs$>
>
> The subject subclause describes how characters or strings are
> "escaped" to be formatted more suitably "for debugging or for
> logging".
>
> The actual suitability for debugging or for logging depends on
> the needs of the application, and there is a conflict between
> formatting for human readability of the textual content and
> formatting for clarity and fidelity of encoding nuances.
> Indeed, for the latter, there can still be (for stateful
> encodings) a conflict between formatting for human visual
> inspection versus formatting for machine consumption of the
> output sequence as a C++ string/character literal.
>
> The current design introduces extensions to the API and to the
> format string syntax that assume that there is one specific
> default that should be chosen "for debugging or for logging".
> The reasoning behind the chosen default and the extensibility
> of the current design does not appear to be sufficiently explored.
>
> Note 1:
> An example, for Unicode encodings, of a choice between
> prioritizing between human readability of the textual content
> and visual clarity of encoding nuances is in the treatment of
> characters having Unicode property Grapheme_Extend=Yes. The
> current design favors visual clarity of encoding nuances by
> outputing such characters as escape sequences.
>
> Note 2:
> For stateful encodings, the lack of return to the initial
> shift state at the end of the sequence cannot be represented
> using a C++ string/character literal unless if a prior shift
> sequence from the initial shift state is rendered via escape
> sequence(s). It is not clear that scanning forward is
> generally always an option (nor is it clear that doing so is
> desirable).
>
> *Proposed change:*
>
> Narrow the purported scope and affirm the design choices of
> the default behavior:
> Modify "logging" to "technical logging" and spell out the
> priorities in order in the description (this has the benefit
> of clearly communicating intention and providing guidance for
> implementation choices).
>
> 1. The output is intended to be a C++ string/character
> literal that reproduces the encoded sequence. (This seems
> to be taken for granted and not made explicit in the
> current draft.)
> 2. Prefer visually distinguishing between different methods
> of encoding "equivalent" textual content.
>
> Make any adjustments necessary to the API or the format string
> syntax associated with "escaped" strings to allow for future
> additions for alternative escaping.
>
>
> US-64: [uaxid.pattern]
> <https://urldefense.com/v3/__https:/eel.is/c**Adraft/uaxid.pattern__;Kys!!EHscmS1ygiU1lA!BObYHCxLPJ4bb2Cfrzw4knCcZud98cCwcpQF-Iw4t1b4p8zqowXOQr-6K0M7Aqtujj9JmRL1nlkDy64$>
>
> The Unicode org has clarified that the pattern whitespace and
> pattern syntax rules apply to the lexing and parsing of
> computer languages.
>
> *Proposed change:*
>
> Replace with "UAX#31 describes how formal languages such as
> computer languages should describe and implement their use of
> whitespace and syntactically significant characters during the
> processes of lexing and parsing. C++ does not claim
> conformance with this requirement."
>
> Tom.
>
>
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
>
>
>
> On Wed, Oct 19, 2022 at 9:22 AM Peter Brett via SG16
> <sg16_at_[hidden]> wrote:
>
> Hi Tom,
>
> I’ve reviewed the British Standards Institute committee’s draft
> comments and I have not found any which require SG16 review.
>
> I personally have been absolutely snowed under with regular work
> during the whole of the comment period and I haven’t even had the
> opportunity to glance at the committee draft.
>
> Best regards,
>
>
> Hey Peter,
> I'm seeing a comment about new-lines/P2348 in the list of GB comments.
> Given that Core decided against the direction of P2348, SG16 might
> want to revisit that question.
I wasn't aware of CWG having made such a decision. The last CWG
discussion I see for P2348 is
https://wiki.edg.com/bin/view/Wg21telecons2022/Teleconference2022-09-09#D2348R3_Whitespaces_Wording_Reva
from 2022-09-09. That discussion was for a draft R3 revision and ends
with "Corentin redrafting". P2348R3 <https://wg21.link/p2348r3> was
submitted for the September mailing. Does the published revision address
CWG's direction? Or was there a more recent discussion I'm not aware of?
Tom.
> Peter
>
> *From:*SG16 <sg16-bounces_at_[hidden]> *On Behalf Of *Tom
> Honermann via SG16
> *Sent:* 18 October 2022 21:31
> *To:* sg16_at_[hidden]
> *Cc:* Tom Honermann <tom_at_[hidden]>
> *Subject:* Re: [SG16] Agenda for the 2022-10-19 SG16 telecon
>
> This is your friendly reminder that this meeting is taking place
> tomorrow.
>
> The German NB has released a draft of their NB comments. None of
> those require review by SG16. As far as I know, no other NB (other
> than INCITS for the US) has released draft comments yet.
>
> Any polling conducted tomorrow will be for changes relative to the
> status quo (the balloted document for which N4917
> <https://urldefense.com/v3/__https:/wg21.link/n4917__;!!EHscmS1ygiU1lA!BObYHCxLPJ4bb2Cfrzw4knCcZud98cCwcpQF-Iw4t1b4p8zqowXOQr-6K0M7Aqtujj9JmRL1cCuaIPY$>
> is close enough); not relative to other NB comments (which some of
> us may or may not have knowledge of).
>
> Tom.
>
> On 10/14/22 12:20 AM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a telecon on Wednesday, October 19th, at 19:30
> UTC (timezone conversion
> <https://urldefense.com/v3/__https:/www.timeanddate.com/worldclock/converter.html?iso=20221019T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest__;!!EHscmS1ygiU1lA!BObYHCxLPJ4bb2Cfrzw4knCcZud98cCwcpQF-Iw4t1b4p8zqowXOQr-6K0M7Aqtujj9JmRL1ljvU2sY$>).
>
> The agenda is:
>
> * NB comment processing.
>
> The details below are a copy of what was originally included
> with the agenda for the October 12th meeting.
>
> INCITS has made US NB comments available to its members. I
> reviewed the list and identified the following as ones that I
> believe SG16 should establish a position on. There are other
> comments that are related to papers SG16 has previously
> discussed, but in those cases, I believe the concerns raised
> do not require SG16 input.
>
> Due to duplicated comments in the list of US comments, it is
> possible that the comment identifiers below will change.
>
>
> US-2: [defns.multibyte]
> <https://urldefense.com/v3/__http:/eel.is/c**Adraft/defns.multibyte__;Kys!!EHscmS1ygiU1lA!BObYHCxLPJ4bb2Cfrzw4knCcZud98cCwcpQF-Iw4t1b4p8zqowXOQr-6K0M7Aqtujj9JmRL1QFFp2co$>
>
> The notion of an "execution character set" is no longer given
> prominence in the Draft standard, aside from some notes about
> its relationship to the concept as defined by C, and
> clarifying that certain character encodings are unrelated to
> this character set. This makes it a questionable choice for
> use in the definition of "multibyte character".
>
> *Proposed change:*
>
> Change the definition of "multibyte character" to use a
> character encoding with a more definite specification given by
> the Standard.
>
>
> US-38: [format.string.escaped]
> <https://urldefense.com/v3/__https:/eel.is/c**Adraft/format.string.escaped__;Kys!!EHscmS1ygiU1lA!BObYHCxLPJ4bb2Cfrzw4knCcZud98cCwcpQF-Iw4t1b4p8zqowXOQr-6K0M7Aqtujj9JmRL1XoaPMxs$>
>
> The subject subclause describes how characters or strings are
> "escaped" to be formatted more suitably "for debugging or for
> logging".
>
> The actual suitability for debugging or for logging depends on
> the needs of the application, and there is a conflict between
> formatting for human readability of the textual content and
> formatting for clarity and fidelity of encoding nuances.
> Indeed, for the latter, there can still be (for stateful
> encodings) a conflict between formatting for human visual
> inspection versus formatting for machine consumption of the
> output sequence as a C++ string/character literal.
>
> The current design introduces extensions to the API and to the
> format string syntax that assume that there is one specific
> default that should be chosen "for debugging or for logging".
> The reasoning behind the chosen default and the extensibility
> of the current design does not appear to be sufficiently explored.
>
> Note 1:
> An example, for Unicode encodings, of a choice between
> prioritizing between human readability of the textual content
> and visual clarity of encoding nuances is in the treatment of
> characters having Unicode property Grapheme_Extend=Yes. The
> current design favors visual clarity of encoding nuances by
> outputing such characters as escape sequences.
>
> Note 2:
> For stateful encodings, the lack of return to the initial
> shift state at the end of the sequence cannot be represented
> using a C++ string/character literal unless if a prior shift
> sequence from the initial shift state is rendered via escape
> sequence(s). It is not clear that scanning forward is
> generally always an option (nor is it clear that doing so is
> desirable).
>
> *Proposed change:*
>
> Narrow the purported scope and affirm the design choices of
> the default behavior:
> Modify "logging" to "technical logging" and spell out the
> priorities in order in the description (this has the benefit
> of clearly communicating intention and providing guidance for
> implementation choices).
>
> 1. The output is intended to be a C++ string/character
> literal that reproduces the encoded sequence. (This seems
> to be taken for granted and not made explicit in the
> current draft.)
> 2. Prefer visually distinguishing between different methods
> of encoding "equivalent" textual content.
>
> Make any adjustments necessary to the API or the format string
> syntax associated with "escaped" strings to allow for future
> additions for alternative escaping.
>
>
> US-64: [uaxid.pattern]
> <https://urldefense.com/v3/__https:/eel.is/c**Adraft/uaxid.pattern__;Kys!!EHscmS1ygiU1lA!BObYHCxLPJ4bb2Cfrzw4knCcZud98cCwcpQF-Iw4t1b4p8zqowXOQr-6K0M7Aqtujj9JmRL1nlkDy64$>
>
> The Unicode org has clarified that the pattern whitespace and
> pattern syntax rules apply to the lexing and parsing of
> computer languages.
>
> *Proposed change:*
>
> Replace with "UAX#31 describes how formal languages such as
> computer languages should describe and implement their use of
> whitespace and syntactically significant characters during the
> processes of lexing and parsing. C++ does not claim
> conformance with this requirement."
>
> Tom.
>
>
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
>
Received on 2022-10-19 19:24:17