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