Thank you for the input.

Didn't know about avoiding templates in `to/from_chars`. Like you said, in this case it would be difficult.

Should've been more explicit. I meant using `formatted_size` with carefully chosen value and assuming info like signed representation, e.g. `numeric_limits<int>::min()`. Then you have the maximum size. Additionally, like you said, the result is not `constexpr`.

I'm curious what do you and other people think about the idea in general? Does it sound like a good addition to the library? Is it worth creating a formal paper and going through the review process?

Best regards,
Mateusz Janek

sob., 20 mar 2021 o 14:58 Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> napisał(a):
The `to/from_chars` interface explicitly avoids the use of templates.
Or rather, the in-specification definition of it does. There's not
really a simple way to avoid that here without introducing a bunch of
function names for no reason.

I think the reasoning behind not using templates was to make it more
acceptable for C to implement the interface. However, the `constexpr`
nature of these APIs makes a non-macro C equivalent API impossible, so
you may as well use template arguments.

You note in the proposal that you could use `formatted_size`, but you
couldn't, as even if it were `constexpr`, it is still computing the
size of a specific value. You're interested in the maximum possible
size.

As to the location of these functions, they should go into the
`charconv` header and the `format` header, since both of them consume
these values. Sticking them in `limits` doesn't really make sense,
since these values are about formatting more than numeric limitations
(that's why they require additional parameters and are functions
rather than variables). Also, it would require that `limits`
include/export parts of `charconv`, since these APIs use
`std::char_format`.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals