Hi OC,
1. not everyone that uses Groovy might be aware that a floting point
number literal will automatically be a BD, so supporting g/G suffix
makes total sense to let a user rest assured on what he will get.
2. In addition, sometimes one wants to express in code that one is
aware of something, in this case that a number literal is a BD,
which again the suffix let's you express that.
3. And finally, to me at least, supporting g/G even if it is
syntactically speaking superfluous, is exactly what makes a language
consistent.
4. What I can see, is that one could want an option to directly express
that a given integer literal shall be treated as a BD, without going
through the rather ugly 1G.toBigDecimal()
1. Which imho is also clearly worse than 1.0G .
2. However, as this might lead to clashes with potential future
Java suffixes I think it would be hard to come up with a good
candidate (?)
1. Which poses the question whether it would be worth the effort...
Cheers,
mg
Am 20.08.2025 um 04:39 schrieb OCsite:
Thanks for the quick reply!
Well primarily I don't get the point of the existence of the BD g/G
suffix at all. So that it works, the number before needs to contain .
or e; but if so, the number is a BD anyway even without the suffix. Is
there /any/ case where the g/G BD suffix wouldn't be completely
superfluous and adding/removing it would change the code behaviour in
the slightest?
Aside of that, there is a /very minute/ and /completely unimportant/
limitation that when I happen to need a BD constant whose value
happens to be integral (eg., 1 or 666), there is (far as I know) no
way to express it with a suffix in a format 1x, 666x (where x would be
the suffix). That's somewhat inconsistent with other cases, e.g., 1f,
666f when the type I happen to need is a float.
Nevertheless of course adding “.0” to get a BD is trivial and works
reliably, thus it's really just a question of consistency, nothing else :)
Thanks and all the best,
OC
On 20. 8. 2025, at 3:46, Paul King <pa...@asert.com.au> wrote:
1g or 1G gives a BigInteger and here the suffix is required to not
get an Integer. Using 1.0g/G for BD seems a natural extension.
Most expressions involving both BI and BD give the results you'd
expect so I believe it was thought at the time that using the same
suffix was sufficient, with toBigInteger() and toBigDecimal()
allowing you to swap between them if really needed.
Do you have a particular scenario that you find that the current
conventions limit you, or are you just noticing the trade-offs that
were made in this case and making sure you fully understand them?
Paul.
On Wed, Aug 20, 2025 at 2:13 AM OCsite <o...@ocs.cz> wrote:
Hi there,
I've just bumped into
https://groovy-lang.org/syntax.html#_number_type_suffixes, namely, to
BigDecimal
|G| or |g|
which seems rather pointless to me. When one enters a decimal
number (e.g., 1.0), it's a BD anyway, suffix or not. On the other
hand, there seems to be no suffix which would allow to write
e.g., just 1s (s for /something/) creating a 1 BD, which would
make some sense, like e.g., 1f for float does.
What do I overlook? What's the point of the BD g/G suffix, and
why there's no suffix which would work without a decimal point
(or exponent)?
Thanks,
OC
