Dario Bertini created GROOVY-7848:
-------------------------------------

             Summary: Closure generic parameters ignored and return types 
missing from collections methods
                 Key: GROOVY-7848
                 URL: https://issues.apache.org/jira/browse/GROOVY-7848
             Project: Groovy
          Issue Type: Bug
            Reporter: Dario Bertini


The theme of this ticket is type failures even specifying the correct input 
parameter type in a Closure, specifically these 2 methods fail to compile with 
CompileStatic/TypeChecked:

{{
        @CompileStatic
        static List foo(){
                [[1,2], [3,4]].collect{List<Integer> pair -> pair[0]+pair[1]}
        }

        @CompileStatic
        static bar(){
                [[1, 3], [1, 2]].transpose().inject(true){acc, List pair -> acc 
&& pair[0] == pair[1]}
        }
}}

The first is due to the generic parameter Integer apparently being ignored.

bq. Error:(15, 48) Groovyc: [Static type checking] - Cannot find matching 
method java.lang.Object#plus(java.lang.Object). Please check if the declared 
type is right and if the method exists.

Ignoring it is just fine when compiling in Dynamic mode, but makes it 
apparently impossible to write a similar Type Safe method

Apparently, this part of the language is as yet undocumented:

http://docs.groovy-lang.org/latest/html/documentation/index.html#generics

The second method instead, has a similar failure to locate Object#getAt(int), 
but the actual error is this one:

bq. Error:(20, 50) Groovyc: Expected parameter of type java.lang.Object but got 
java.util.List

Which is imho a bit unhelpful: I'm obviously passing it a List, at runtime... 
and the the Closure parameter type is List, given that I would expect the error 
to be the other way around: expected parameter of type List, but got Object

But the problem is not actually with Closure types, inference or the like... I 
suspect it might simply be an imprecise type specified for transpose() result: 
it should be List<List>, but is instead List (once I understood this I simply 
created an intermedia variable with the explicit type as a workaround)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to