From 389f0d1e55cced36659e5123a622e9ca4b731877 Mon Sep 17 00:00:00 2001 From: Howard Hinnant Date: Thu, 5 Oct 2023 15:38:12 -0400 Subject: [PATCH] Initial version --- rebuttal.html | 174 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 174 insertions(+) create mode 100644 rebuttal.html diff --git a/rebuttal.html b/rebuttal.html new file mode 100644 index 0000000..0cedd34 --- /dev/null +++ b/rebuttal.html @@ -0,0 +1,174 @@ + + + + + Rebuttal to Additional format specifiers for time_point + + + +
+Document number: DxxxxR0 +
+Date: 2023-10-05 +
+Audience: Library Evolution Working Group +
+Reply-to: Howard E. Hinnant
+
+
+

Rebuttal to Additional format specifiers for time_point

+ +

Contents

+ + + +

Introduction

+ +

+This paper is written to express strong opposition to changing the +meaning of %S as proposed in P2945R0. To be perfectly clear, this paper expresses no +objection to adding syntax to specify precision to %S. +This would not break any code. The only objection is to changing the +meaning of %S from representing seconds exactly, to +representing only the integral part of seconds. +

+ +

+Having a standard specify run-time changes to existing code is +BadTM +

+ +

+The proper way to change a standard is to deprecate the old behavior, +and provide new syntax for the new behavior. Let both behaviors +coexist for a few cycles, then remove the deprecated specification. +

+

+Doing otherwise risks introducing run-time errors to existing code by +simply upgrading to a new version of C++. Such run-time errors have +the potential for raising safety and security issues. +

+ +

+The %S flag as specified in the +<chrono> library is existing code +

+ +

+It has been shipping in MSVC for over a year now. +

+

+It has been implented in gcc 14.0.0. +

+

+%S has been documented by the standard, by books, by +countless informal articles and postings, and by my date library. +

+

+%S has 7 years of positive field experience with this +syntax and behavior in my date library. +

+ +

+%S is a good design +

+ +

+The design of %S follows the principles first laid down +by the C++11 version of <chrono>. +<chrono> does not implicitly throw away +information. This is true in conversion of units, and it remains true +in formatting. All information is preserved unless truncating +behavior is explicitly requested. And when it is explicitly +requested, there exists options on which way to truncate: towards +zero, towards negative infinity, towards postive infinity, or to +nearest. +

+ +

+<chrono> was precision-neutral in C++11, and +remains so a decade later in C++23. From N2661, written 2008-06-11: +

+ +
+

+This paper proposes a solution that is precision neutral. +

+
+ +

+No single precision is promoted above others or given special +priviledges. It is not up to <chrono> to decide +that one precision is better than another. That decision is up to the +OS which talks directly to the hardware. And up to the client, who +knows what precision is best for their application. +<chrono> is just a middleman to make the syntax +between the OS and the client portable. +

+ +

+Clients often change the OS’s precision to their specification’s +precision at the point of input, such as wrapping a call to now: +

+ +
+auto
+GetCurrentTime()
+{
+   using namespace std::chrono;
+   return floor<milliseconds>(system_clock::now());
+}
+
+ +

+And then traffic in those time_points throughout their +library or application. There may be many points of both formatting +and parsing involved throughout their application. And at each point +they don’t have to worry about synchronizing their parse and format +statements with their specification’s precision. They can just ask +for the time: “%F %T” (etc.). And when their +specification changes, there is no pain point. Formatting and parsing +by default automatically adjust. +

+ +

+<chrono> does not (and should not) carry all of +this respect for the client around and then when the client gets ready +to create a logging statement suddenly say: Oh, you probably want the +precision a bunch of committee members decided upon. No, +<chrono> should give the client the preicsion he +has already asked for (as the default, of course there should be a way +to change it). +

+ +

+Clients also value symmetry between the parsing and formatting strings +so that they only have to learn one micro-language and not two. +During parsing %S takes its precision from the type being +parsed, and reads up to that amount of precision from the input +stream. A piece-wise redesign of <chrono> without +an in-depth knowledge of the entire library is foolhardy at best. And +in this case also disruptive and dangerous. +

+ +

+%S does not need to have identical functionality to other +languages. There are many ways in which <chrono> +differs from other date time libraries. These differences are what +makes the <chrono> solution superior, in +safety, functionality and performance. +

+ + +