On 21.11.19 17:05, Milles, Eric (TR Tech, Content & Ops) wrote: [...]
*Do we expect number literals (such as BigDecimal, BigInteger or even just Double) to be acceptable arguments to methods that accept "int", "double" or "String"? Is there some limited set of automatic conversions that STC should support?* Dynamic Groovy supports the m1 and m2 calls, but throws MissingMethodException for m3.@groovy.transform.CompileStatic class STC { void m1(int i) {} void m2(double d) {} void m3(String str) {} void test() { m1(1.0) m2(1.0) m3(1.0) } } https://issues.apache.org/jira/browse/GROOVY-8488 https://issues.apache.org/jira/browse/GROOVY-9224
you have not to forget that in Java 1.0 is a double. Part of the "trouble" stems from 1.0 being a BigDecimal in Groovy. This leads to differences in behaviour between Java and Groovy and the static compiler orientates itself even more at Java. Assuming you do not want to change that, the rule for the static compiler was to allow calls in which you do not loose precision. (dynamic Groovy checks that partially at runtime). 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. As for m3. I am ok with type transformations in explicit or implicit casts, but I do not see a method call as having the same logic as a cast - especially not with our much more "powerful" casts. So I think that should be rejected in static or not. bye Jochen
