Re: Decimal: Formal review begins.

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2025-01-18 11:55:21

> > 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 program
> that uses one data table for a type
> T that could be decimal32, 64 or 128.
> But you only wanted one table.
>
> You would make the table entries with
> the highest width suffix and decorate
> each table entry with a static-cast
> to T in order to get all the table
> entries into type T.
>
> To be fair, everyone already has to
> do something like this with normal
> float, 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 recipe
> on how to deal with this in generic
> code above. My judgement may have
> been hurried and might seem unfair.
>
> But my intuition tells me, a whole
> bunch of clients would run into
> compilation failures. Until they
> come up with their own recipes for
> generic literal values.
>
> And the result would be more
> frustration than had we simply
> done nothing.
>
> This is what my intuition and
> experience tells me.

I will trust your experience here, as it's much wider than mine.

Thanks,
Ruben.

>
> - 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
> >
> >