[
https://issues.apache.org/jira/browse/GROOVY-11486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935790#comment-17935790
]
ASF GitHub Bot commented on GROOVY-11486:
-----------------------------------------
eric-milles opened a new pull request, #2157:
URL: https://github.com/apache/groovy/pull/2157
I tried to follow `collectMany` in terms of generics. There is no
connection that can be made between the in type and the out type, since
aggregates are recursively processed. And the closure accepting forms have
weaker guarantees for the parameter type, so I added `@ClosureParams` just to
indicate the number of parameters.
https://issues.apache.org/jira/browse/GROOVY-11486
> DGM flatten return type is often incorrect
> ------------------------------------------
>
> Key: GROOVY-11486
> URL: https://issues.apache.org/jira/browse/GROOVY-11486
> Project: Groovy
> Issue Type: Bug
> Reporter: Eric Milles
> Assignee: Eric Milles
> Priority: Major
>
> The groovy method {{flatten}} for {{Object[]}}, {{Collection}}, {{Iterable}},
> {{List}}, {{Set}} and {{SortedSet}} does not inference to the correct return
> type except for the case where there were no aggregate elements to flatten.
> There isn't anything the type checker can do to detect the return type for
> non-trivial cases, but the {{flatten}} methods that accept a transform are a
> reasonable model:
> {code:java}
> public static <T, E> Collection<T> flatten(Iterable<E> self, Closure<?>
> flattenUsing) {
> // ...
> }
> {code}
> This allows the programmer to declare the expected type:
> {code:groovy}
> def list = [1,[2],[[3],[4]]]
> Collection<Integer> coll = list.flatten(Closure.IDENTITY)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
