Re: Decimal: Formal review begins.

From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2025-01-18 09:25:55

 >>> 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"
<snip>
>> So if you think it doesn't add>> enough value, I understand it.
> Now I'm liking this idea.
But my final advice goes like this,and you probably won't like it.
It will detract value. Clientsmaking data tables will constantlywonder why they are hitting allkinds of compiler problems.
When writing code for severalwidths of types, there might needto be separate sets of literalconstants for different decimalwidths (unless the highest widthwere taken for table entires andstatic_cast-ing were judiciouslyused).
And this whole great idea will turninto more of a mess than a help.Clients would get discouragedand this would ultimately reducelibrary acceptance and tractiongaining.
I would advise avoiding theoreticallycool-seeming compile-time assertslike these.
- Chris

    On Saturday, January 18, 2025 at 08:51:02 AM GMT+1, Christopher Kormanyos <e_float_at_[hidden]> wrote:  
 
   >>> 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"
<snip>
> Example about compile-time throw> message indication
> 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.
I think we have all those idiomswithin a C++-14-constexpr context.So we would just need to collectthem.
> So if you think it doesn't add> enough value, I understand it.
I was just thinking to myself,prior to reading this post,hey, wouldn't it make more senseif we catch this at compilet-time?
Now I'm liking this idea.
If we end up doing it or somethinglike it, why would we throw()instead of static_assert-ing it?Wouldn't static_assert be better?
- Chris

    On Friday, January 17, 2025 at 11:04:48 PM GMT+1, Ruben Perez <rubenperez038_at_[hidden]> wrote:  
 
 On Fri, 17 Jan 2025 at 22:57, Christopher Kormanyos via Boost
<boost_at_[hidden]> wrote:
>
>Â  >>> 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.