This is a terrible user experience, and the opposite of "make simple things simple". Why not just have a constructor that constructs the decimal from a string?
I noted the literals, but these are irrelevant as the pain will come when accepting text inputs and building decimals from them.
As things stand I think boost.multiprecision remains a better solution because of this one feature.
There's not been any demand for a string constructor is really the main reason there isn't one. Would you want the behavior of a theoretical constructor to match the behavior of chars_format::general, much like from_chars without a specified format? That would be nothing more than a thin wrapper which is easy to implement.
I appreciate that John's intent is to implement the standard verbatim, but this has frankly never been a good idea.
Almost all financial systems (an obvious candidate for a class such as this) spend most of their time converting decimals to strings and strings to decimals. I see that serialisation is covered by fmt integration, but what about parsing?
R
Does {fmt} even support parsing beyond parsing of the context? I am not aware of that if it does.
I did not mean to imply that {fmt} includes parsing. Merely that serialisation is covered by {fmt}, but that parsing is not covered (other than by the from_chars complication).
Something that makes from_chars slightly easier (and is divergent from the STL) is that by popular demand both here, and in Boost.Charconv, from_chars accepts std::string and std::string_views in addition to a pointer pair. Matt