Chiming in late here, but the only one I would passionately argue about is
the string <=> numeric conversions. The implicit conversions to / from
String already in Groovy have been responsible for a large proportion of
the impactful bugs that have come out of my complex groovy code. For
example, the fact that this code both compiles and passes the assertion:
@CompileStatic
class Foo {
String bar() {
return 3
}
}
assert new Foo().bar() == "3"
I guess removing this implicit conversion would break things, but I
personally would gladly take the hit in transitioning to Groovy 3.x :-)
Cheers,
Simon
On Fri, Nov 22, 2019 at 3:08 AM Milles, Eric (TR Tech, Content & Ops) <
eric.mil...@thomsonreuters.com> wrote:
> I wanted to discuss the strictness of Groovy's static type checking before
> Groovy 3 is released and change becomes difficult. Recent changes have
> replaced some instances of type coercion with STC errors. It was suggested
> in one of the bug tickets to discuss before accepting the new strictness or
> making some adjustments to allow some number type conversions and possibly
> allow toString() conversions.
>
> Each of the three method call expressions below produce this error:
> "[Static type checking] - Cannot find matching method
> bugs.Groovy8488#m1(java.math.BigDecimal). Please check if the declared type
> is correct and if the method exists."
>
> *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
>
