[charconv] Review Results and Report

From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2024-02-02 16:31:12


Dear Boost Community,

The review of the proposed
Boost.Charconv is finished
It took place 15-25 January 2024.

REVIEW RESULT
-----------------------------

The result is Boost.Charconv is
unconditionally
* ACCEPTED * into Boost.

Thank you Matt. Boost.Charconv
will enrich Boost and surely
be used vigorously.

REVIEW REPORT
-----------------------------

The review tally is:

* 1 Conditional ACCEPT
* 4 ACCEPT
* 1 Positive Document Review
----------------------------
= 5 ACCEPT, since the single
condition has already been
satisfied in develop branch.

My Comments and Descriptions
below are based on limited
knowledge and my subjective
interpretations. Please correct,
add, modify these (and to these)
as needed.

* Comments:

The review atmosphere was highly
productive and excellent. Reviews
and contributions featured deep
technical content and detail.

Fact-based statements combined
with experienced-based
opinions were provided.
There was great strength of
expression and clarity.
Yet there was mutual respect
and fairness, even in the
course of lively debate.

* Descriptions:

Ultimately there were three areas
receiving the most debate.
For background, see references below.

1) The library needs to allocate.
Among other conversions,
Boost.Charconv handles conversion
of floating-point values to chars.
Edge-cases may require hundreds
or even thousands of bits.

* Consensus: Handle the required
memory needed, as done, with
low-level C-LIB malloc. But
do describe this decision
with greater depth of clarity
in the docs.

2) The project makes use of
a variety of methods, including
some table-driven methods.
One example is RYU (see [1]).
A quick glance at Fig. 4 in [1],
for instance, reveals the need
for relatively large, constant-valued
tables. Largescale tables,
combined with the C++11 design goal
formed a clear indication
to produce a compiled library
(as opposed to a header-only one).

* Consensus: Compiled-library is
sound and viable. Tables (especially
in constexpr-context) might bloat
or not even work in some
language-standards environments.
Some commenters, however, seemed
subjectively to disapprove of this
consensus, feeling that header-only
offers the best chances at
friction-free setup and convenient
portability. Other commenters
revealed a sense that compiled
libraries are gaining traction
in the industry. They feel that
this is because the community,
their available tools,
language-skills, specifications,
compilers, CI, VMs, etc.
have matured significantly and
continue to mature. Thereby
they embrace a perceived
future-oriented trend that views
client-builds to be uncomplicated.
There were no blockers
on the consensus.

3) The top-level interface differs
from that of std-<charconv> in points
such as overloads and error-handling.
Whereas some details are not even
fully hashed-out in the Standard.

* Consensus: Weigh known opinions
and decide interface details
based on unbiased majority.
My current understanding is:
Offer two drop-ins for
from_chars, with the caveat
that one should provide better
error-handling.

REVIEW ACKNOWLEDGMENTS
-----------------------------

Thanks again, Matt for
Boost.Charconv.

Many thanks to our expert
reviewers, commenters and
watchers. Your contributions
keep Boost excellent!

Kindest regards,
Christopher Kormanyos
Boost.Charconv Review Manager

* References:

[1] Ulf Adams, "RYU: fast
float-to-string conversion",
ACM SIGPLAN Notices, Volume 53,
Issue 4, pp 270–282 (ACM 2018)

[2] "Number Parsing at a Gigabyte
per Second", Daniel Lemire's Blog,
https://lemire.me/blog/2021/01/29/number-parsing-at-a-gigabyte-per-second/

[3] https://github.com/lemire/fast_double_parser