On Fri, 17 Jan 2025 at 22:57, Christopher Kormanyos via Boost
Question:>>> I've noticed that this:>>>>>> 1.23456789098787237982792742932938492382342382342002934932_df>>> Compiles, although it truncates the>>> value to 1.234568. Would it make>>> sense to somehow tell the user "hey,>>> this literal is too long" It would absolutely make sense,>> but then you would need the same thing>> to happen for float, double and>> long double in the Standard, which>> isn't going to happen.>> So Decimal follows suit. That's not the same. Base 2 floats> don't need a fixed number of decimal> digits to be represented unambiguously,> but decimal floats do. Oh that's a good point. It goesinto the direction of languagespecification. When we talk about adding valueto this library today, we couldhave the discussion. I guesswe would need to figure out a portableway to provide such compile-time info. This might seem a bit skeptical frommy side, but, as much as I agree,I don't feel that it really leadsanywhere in the case of DecimalTODAY. I don't believe it's within the scopeor purpose of Decimal to figureout how to inform the client"Hey, your fixed-point representationjust walked off its digits". That would be something for theStandard, and perhaps evensomething for fixed-point ingeneral.
I was thinking of something along the lines: BOOST_DECIMAL_EXPORT consteval auto operator ""_dd(const char* str, std::size_t) -> decimal64 { decimal64 d; bool has_precision_error = detail::from_chars_report_loss_of_precision(str, str + detail::strlen(str), d); if (has_precision_error) throw std::runtime_error(); // throwing in a consteval function just yields a compile time error return d; } In a similar spirit to what fmtlib does to error at compile time when you make a mistake with format arguments. Of course, this requires a bunch of ifdefs to make it work in C++14. So if you think it doesn't add enough value, I understand it. Regards, Ruben.