Date: Thu, 15 Oct 2020 10:38:54 +0000
Hi Niall,
I regret that this is yet another paper that has entirely shed its rationale and design discussion in the process of revision.
A paper that contains wording without the context that led to that wording is difficult to review because it is hard to verify that the wording accurately reflects the design intent. Per P2000R2, section 7.5:
> [W]e have observed that the rationale and design parts
> are often left out of later documents containing
> wording and often not maintained to reflect decisions
> during the time taken to process the proposal. This
> time is typically multiple years and covers multiple
> meetings in multiple WGs. This can be a significant
> barrier to understanding and a source of confusion.
> For example "Is the wording in Pxxxx supposed to
> reflect the design in Pyyyy?” How would I know? It
> can be significant work finding out, often involving
> searching through the wikis for multiple meetings.
> Non-members of the committee cannot do that, so they
> really can’t understand what is being proposed.
>
> ...
>
> We therefore suggest that the rationale and design
> discussions from early papers are carried through and
> maintained in later wording documents. This makes
> documents larger, but people can skip what they don’t
> feel the need to read. Having all in a single document
> also provides redundancy that can help spot mistakes.
> It should also help decrease the confusion that often
> happens when a proposal comes up for final vote so
> that people who have not been following the proposal
> closely have to catch up.
Since this a 'D' paper at the moment, I hope that you will have the opportunity to integrate updated motivation and design discussion sections into the paper before today's mailing deadline.
Best regards,
Peter
> -----Original Message-----
> From: Lib-Ext <lib-ext-bounces_at_[hidden]p.org> On Behalf Of Niall Douglas
> via Lib-Ext
> Sent: 15 October 2020 11:18
> To: sg16 <sg16_at_[hidden]>; C++ Library Evolution Working Group <lib-
> ext_at_lists.isocpp.org>; Billy O'Neal (VC LIBS) <bion_at_microsoft.com>; Corentin
> <corentin.jabot_at_[hidden]>
> Cc: Niall Douglas <s_sourceforge_at_nedprod.com>
> Subject: [isocpp-lib-ext] D1030R4 draft 2: std::filesystem::path_view
>
> EXTERNAL MAIL
>
>
> LEWG, SG16,
>
> CC: Billy, Corentin
>
> Please find attached draft 2 of proposed normative wording for D1030R4
> std::filesystem::path_view. Changes since draft 1:
>
> - The reference implementation has been upgraded to match this proposed
> wording, and has been found to work well.
>
> - For all existing path consuming overloads, no longer remove the
> existing overloads, instead add weakly selected path view overloads.
>
> - Path view components now default to not interpreting path separators.
>
> My thanks in advance to anyone willing to review this draft before it
> gets formally submitted for LEWG to review next mailing. Please don't do
> a deep dive on the normative wording yet though, as LEWG needs to sign
> off on this design first.
>
> Niall
I regret that this is yet another paper that has entirely shed its rationale and design discussion in the process of revision.
A paper that contains wording without the context that led to that wording is difficult to review because it is hard to verify that the wording accurately reflects the design intent. Per P2000R2, section 7.5:
> [W]e have observed that the rationale and design parts
> are often left out of later documents containing
> wording and often not maintained to reflect decisions
> during the time taken to process the proposal. This
> time is typically multiple years and covers multiple
> meetings in multiple WGs. This can be a significant
> barrier to understanding and a source of confusion.
> For example "Is the wording in Pxxxx supposed to
> reflect the design in Pyyyy?” How would I know? It
> can be significant work finding out, often involving
> searching through the wikis for multiple meetings.
> Non-members of the committee cannot do that, so they
> really can’t understand what is being proposed.
>
> ...
>
> We therefore suggest that the rationale and design
> discussions from early papers are carried through and
> maintained in later wording documents. This makes
> documents larger, but people can skip what they don’t
> feel the need to read. Having all in a single document
> also provides redundancy that can help spot mistakes.
> It should also help decrease the confusion that often
> happens when a proposal comes up for final vote so
> that people who have not been following the proposal
> closely have to catch up.
Since this a 'D' paper at the moment, I hope that you will have the opportunity to integrate updated motivation and design discussion sections into the paper before today's mailing deadline.
Best regards,
Peter
> -----Original Message-----
> From: Lib-Ext <lib-ext-bounces_at_[hidden]p.org> On Behalf Of Niall Douglas
> via Lib-Ext
> Sent: 15 October 2020 11:18
> To: sg16 <sg16_at_[hidden]>; C++ Library Evolution Working Group <lib-
> ext_at_lists.isocpp.org>; Billy O'Neal (VC LIBS) <bion_at_microsoft.com>; Corentin
> <corentin.jabot_at_[hidden]>
> Cc: Niall Douglas <s_sourceforge_at_nedprod.com>
> Subject: [isocpp-lib-ext] D1030R4 draft 2: std::filesystem::path_view
>
> EXTERNAL MAIL
>
>
> LEWG, SG16,
>
> CC: Billy, Corentin
>
> Please find attached draft 2 of proposed normative wording for D1030R4
> std::filesystem::path_view. Changes since draft 1:
>
> - The reference implementation has been upgraded to match this proposed
> wording, and has been found to work well.
>
> - For all existing path consuming overloads, no longer remove the
> existing overloads, instead add weakly selected path view overloads.
>
> - Path view components now default to not interpreting path separators.
>
> My thanks in advance to anyone willing to review this draft before it
> gets formally submitted for LEWG to review next mailing. Please don't do
> a deep dive on the normative wording yet though, as LEWG needs to sign
> off on this design first.
>
> Niall
Received on 2020-10-15 05:39:02