Re: [boost] Decimal: Formal review begins.

...

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

On Sat, 18 Jan 2025 at 10:26, Christopher Kormanyos 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