On 23.11.19 03:08, MG wrote:
On 22/11/2019 17:51, Jochen Theodorou wrote:
So strictly spoken none of the calls to m1 and m2 should be supported
here. But this is a problem for the user, as the user is not used to
write 1.0d instead. And it will make a lot of programs cumbersome. But
it would be more correct.
I know you are arguing both sides, but I think we should be careful not
to go down the easy route of being formally more correct (which is, of
course, by definition less messy / requires less thought than the
alternatives): Same as Java code can be pasted into Groovy, and it "just
works" 99.99999...% of the time, I think we should strive for Groovy
code to continue to compile & work as before where possible when the
code is annotated with @CompileStatic, without giving up on one of the
goals of static compilation, namely spotting (trivial) errors at compile
time / being more safe.
What I was hinting at actually was that to follow the Java rules 1.0
would have to be a double. If you say we cannot do that, you have to
acknowledge, that we cannot fully follow the Java rules here. Well, not
you specifically, but anyone reading this.
If we say it is legal to call a double taking method with a BigDecimal,
then why not any other number type? In fact why not also using double to
call anything from byte to BigInteger and float or BigDecimal?
The argument was to fail compilation because of the possible loss of
precision. If we want to be clear here, and want not to change basic
semantics of the language, then we have to disallow all kinds of calls
in static mode. This is not acceptable, because then even copied Java
programs would no longer statically compile in groovy as soon as they
use floating point literals. But if we do not accept that, then the
principle that must fall is failing to compile in case of loss of
precession for floating points. Then the call to m2 is legal.
You say the call to m1 should be not be legal, but this is partially
about the convenience of writing and partially about defining easy to
follow rules. So if we allow calling an int method with a BigDecimal,
and if BigDecimal, float and double can be freely exchanged, then it
follows for me that all floating point calls to all integer arguments
(byte, short, int, long, BigInteger) should be legal as well.
And if m2(1) should be legal as well, then why not byte to double or
BigInteger to double? Of course some longs/BigIntegers do not fit into a
double without loosing information. But we already accepted information
loss in floating point number transformation before. It is difficult why
now it suddenly should be important.
And really I am only trying to built an argumentative base for a
decision here ;)
bye Jochen
