2. For each decimal size, there's two types: decimal32 is the storage optimized one, and decimal32_fast is the operation-optimized one. Like Peter, I'm not convinced that making the storage optimized be the default one is adequate. I understand that this is what the TR states, though. I'd advise to consider Peter's suggestions [1] [2]. I don't have enough field experience to know whether this is sufficiently relevant, though. In any case, the documentation should state when to use the standard ones vs the fast ones.
In this case it is the naming scheme provided by IEEE-754, which I think we would be remiss to ignore. I think the suggestion from Peter (and you below in bullet 3) to add implicit lossless conversions is good. <stdfloat> has far stricter rules than builtin floating point types but allows promotion up implicitly, but errors on shortening.
That's fair.
If you're not going to support all standard type specifiers, I'd think of exposing a std::format-like function that works in C++14. Something like decimal::format_decimal and decimal::print_decimal. This is just a suggestion, though. I understand that, if this is pushed to the standard, having these functions might be valuable.
The implementations of those functions was more in the realm of reference for how you would add the functionality to the existing STL should they be standardized. Making a complete working reimplementation of all those clib functions would be a huge undertaking for little benefit.
Since <charconv> is available at C++14 doesn't that generally cover what format_decimal, and print_decimal would do? I specifically avoided using the STL here because requiring C++17 for a two member struct and an four member enum seemed silly.
Yes, that's fair, too. Charconv should be enough.
9. Is boost::decimal::to_string public? It's handy, and in the public namespace, but in a detail/ header and not documented. I'd advise to make it public by moving the header to boost/decimal/ and documenting it.
I'll move it. I think it goes along with your printing point, and is generally something I would expect to be provided for a numeric type.
I discovered it through the IDE and I think it's a useful thing. I think this is the right thing to do. Thanks, Ruben.