Re: Decimal: Formal review begins.

From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2025-01-18 11:48:33

 >> It will detract value. Clients>> making data tables will constantly>> wonder why they are hitting all>> kinds of compiler problems.>>>> When writing code for several>> widths of types, there might need>> to be separate sets of literal>> constants for different decimal>> widths (unless the highest width>> were taken for table entires and>> static_cast-ing were judiciously>> used).
> I think I'm not following you here.
I think honestly I'm being a bitunfairly terse here.
> Could you illustrate such a use case?> Concretely, what do you mean by> several widths of types? Do you> mean decimal32 vs decimal64?
Yes. Let's say you made a programthat uses one data table for a typeT that could be decimal32, 64 or 128.But you only wanted one table.
You would make the table entries withthe highest width suffix and decorateeach table entry with a static-castto T in order to get all the tableentries into type T.
To be fair, everyone already has todo something like this with normalfloat, double and long double.
> With the syntax you have today,> you already have distinct suffixes> for each type (i.e. _df always constructs> decimal32, _dd always constructs decimal64,> and so on).
Yes. And I gave one potential recipeon how to deal with this in genericcode above. My judgement may havebeen hurried and might seem unfair.
But my intuition tells me, a wholebunch of clients would run intocompilation failures. Until theycome up with their own recipes forgeneric literal values.
And the result would be morefrustration than had we simplydone nothing.
This is what my intuition andexperience tells me.
- Chris

    On Saturday, January 18, 2025 at 12:35:58 PM GMT+1, Ruben Perez <rubenperez038_at_[hidden]> wrote:  
 
 On Sat, 18 Jan 2025 at 10:26, 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>
>
> >> 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.

Well, I don't have a strong opinion about this. You have much more
field experience about this than me, so you're best suited to make the
final decision.

I'd like to understand your reasoning though.

>
> It will detract value. Clients
> making data tables will constantly
> wonder why they are hitting all
> kinds of compiler problems.
>
> When writing code for several
> widths of types, there might need
> to be separate sets of literal
> constants for different decimal
> widths (unless the highest width
> were taken for table entires and
> static_cast-ing were judiciously
> used).

I think I'm not following you here. Could you illustrate such a use case?
Concretely, what do you mean by several widths of types? Do you mean
decimal32 vs decimal64? With the syntax you have today, you already
have distinct suffixes for each type (i.e. _df always constructs
decimal32, _dd always constructs decimal64, and so on).

>
> And this whole great idea will turn
> into more of a mess than a help.
> Clients would get discouraged
> and this would ultimately reduce
> library acceptance and traction
> gaining.
>
> I would advise avoiding theoretically
> cool-seeming compile-time asserts
> like these.
>
> - Chris
>
>