You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Paul King (JIRA)" <ji...@apache.org> on 2018/08/26 02:51:00 UTC

[jira] [Updated] (GROOVY-7848) Closure generic parameters ignored and return types missing from collections methods

     [ https://issues.apache.org/jira/browse/GROOVY-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul King updated GROOVY-7848:
------------------------------
    Description: 
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:

{code}
@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]}
}
{code}

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)

  was:
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)


> 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
>            Priority: Major
>
> 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:
> {code}
> @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]}
> }
> {code}
> 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
(v7.6.3#76005)