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