[ https://issues.apache.org/jira/browse/GROOVY-10714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780034#comment-17780034 ]
Eric Milles commented on GROOVY-10714: -------------------------------------- I have experimented with computing SAM-type distance first for {{Callable}}, {{GroovyCallable}} and {{Runnable}}. Thus their distance would increase to 12 or 13. Doing so in the presence of {{Cloneable}}, {{Serializable}}, {{GroovyObject}} or {{GroovyObjectSupport}} overloads would be a change in selection. And the current preference of {{Runnable}} over {{Callable}} would break without some further adjustment. This applies equally to closures, lambdas, method pointers and method references. STC treats them all as {{Closure}} in terms of argument type during method selection. > STC: Callable, Runnable, Serializable overload preference for functional > argument (closure, lambda, etc.) > --------------------------------------------------------------------------------------------------------- > > Key: GROOVY-10714 > URL: https://issues.apache.org/jira/browse/GROOVY-10714 > Project: Groovy > Issue Type: Bug > Components: Static compilation > Affects Versions: 4.0.4 > Reporter: Christopher Smith > Assignee: Eric Milles > Priority: Minor > > This appears to be similar to GROOVY-9881, but it's specifically in the > method-overload procedure. Given a functional value type with two method > overloads: > {code} > interface Try<T> { > Try<T> andThenTry(Consumer<? super T>) > Try<T> andThenTry(Runnable) > } > {code} > When this code is invoked from static code, the STC errors out on an > ambiguous method reference even if the method type isn't: > {code} > // AWS SDK 2 DynamoDbTable > class DynamoDbTable { > void putItem(PutItemRequest<T>) > void putItem(Consumer<PutItemRequest.Builder<T>) > void putItem(T) > } > @CompileStatic > class MyServiceClass { > void doThing() { > Try.success(putItemRequest()) > .andThenTry(table::putItem) // T for Try<T> is PutItemRequest<I> > } > } > {code} > produces > {code} > [Static type checking] - Reference to method is ambiguous. Cannot choose > between [Try<T> Try#andThenTry(Consumer<? super T>), Try<T> > Try#andThenTry(Runnable)] > {code} > I think this may have something to do with the relaxed SAM matching that is > used to bridge ambiguous closure syntax, but when a plain method reference is > used, there's no ambiguity available. -- This message was sent by Atlassian Jira (v8.20.10#820010)