[jira] [Comment Edited] (GROOVY-10714) STC: Callable, Runnable, Serializable overload preference for functional argument (closure, lambda, etc.)

["Eric Milles (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-10714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17574283#comment-17574283 ] 

Eric Milles edited comment on GROOVY-10714 at 12/7/22 2:54 PM:
---------------------------------------------------------------

There are a couple of things at play here. When looking at a method call, the type checker first visits the arguments to determine the types to use for method selection. For the method reference "table::putItem" this means checking for the methods "putItem" from your table type. At this point, {{Closure<CommonReturnType>}} is used as the type. Under STC not SC, a method reference produces a {{{}MethodClosure{}}}.

Next, the method "andThenTry" is looked up using the argument types. In this case, "andThenTry(Consumer)" and "andThenTry(Runnable)". To select from multiple options, a distance calculation is made. Since {{Closure}} actually implements {{{}Runnable{}}}, it is deemed much closer than {{{}Consumer{}}}. I'm not sure why you are seeing smbiguous method error when I am getting method selected unambiguously but then reference fails type-checking.

It is not until after selecting the target method that parameter types can be used to clarify argument types.


was (Author: emilles):
There are a couple of thing at play here.  When looking at a method call, the type checker first visits the arguments to determine the types to use for method selection.  For the method reference "table::putItem" this means checking for the methods "putItem" from your table type.  At this point, {{Closure<CommonReturnType>}} is used as the type.  Under STC not SC, a method reference produces a {{MethodClosure}}.

Next, the method "andThenTry" is looked up using the argument types.  In this case, "andThenTry(Consumer)" and "andThenTry(Runnable)".  To select from multiple options, a distance calculation is made.  Since {{Closure}} actually implements {{Runnable}}, it is deemed much closer than {{Consumer}}.  I'm not sure why you are seeing smbiguous method error when I am getting method selected unambiguously but then reference fails type-checking.

It is not until after selecting the target method that parameter types can be used to clarify argument types.

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