[
https://issues.apache.org/jira/browse/GROOVY-10905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-10905:
-------------------------------
Description:
When matching Closures to SAM types, we have special treatment for Closures
without a formal parameter section. Such Closures may have 0 or 1 arguments,
e.g.:
{code}
foo { println 42 } // zero-arg case
bar { println 'arg:' + it } // one-arg case
{code}
Our current matching says that because of this ambiguity, we know nothing about
the number of parameters, but this assumption is throwing away information: the
fact that we are expecting 0 or 1 args. I'd like to propose for Groovy 5 that
we match 0 or 1-arg SAMs more closely that say a 2-arg SAM for such a Closure.
The impact of this is that there will be less ambiguity errors (or conversely,
less places where we need to cast to get the correct method). It obviously
doesn't help if there are both 0 and 1-arg options available, where casting
would still be required.
Examples:
{code}
def method1(IntUnaryOperator unary) { '1a' }
def method1(IntBinaryOperator binary) { '1b' }
// unchanged behavior
assert method1{ a -> } == '1a'
assert method1{ a, b -> } == '1b'
assert method1({ } as IntUnaryOperator) == '1a'
assert method1({ } as IntBinaryOperator) == '1b'
// proposed change: implicit arg will match Unary over Binary since Unary is
the only match for 0 or 1 args
assert method1{ } == '1a'
{code}
was:
When matching Closures to SAM types, we have special treatment for Closures
without a formal parameter section. Such Closures may have 0 or 1 arguments,
e.g.:
{code}
foo { println 42 } // zero-arg case
bar { println 'arg:' + it } // one-arg case
{code}
Our current matching says that because of this ambiguity, we know nothing about
the number of parameters, but this assumption is throwing away information: the
fact that we are expecting 0 or 1 args. I'd like to propose for Groovy 5 that
we match 0 or 1-arg SAMs more closely that say a 2-arg SAM for such a Closure.
The impact of this is that there will be less ambiguity errors (or conversely,
less places where we need to cast to get the correct method). It obviously
doesn't help if there are both 0 and 1-arg options available, where casting
would still be required.
Examples:
{code}
def method1(IntUnaryOperator unary) { '1a' }
def method1(IntBinaryOperator binary) { '1b' }
{code}
> Improve matching no-arg closures to SAM types
> ---------------------------------------------
>
> Key: GROOVY-10905
> URL: https://issues.apache.org/jira/browse/GROOVY-10905
> Project: Groovy
> Issue Type: Improvement
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
> Fix For: 5.x
>
>
> When matching Closures to SAM types, we have special treatment for Closures
> without a formal parameter section. Such Closures may have 0 or 1 arguments,
> e.g.:
> {code}
> foo { println 42 } // zero-arg case
> bar { println 'arg:' + it } // one-arg case
> {code}
> Our current matching says that because of this ambiguity, we know nothing
> about the number of parameters, but this assumption is throwing away
> information: the fact that we are expecting 0 or 1 args. I'd like to propose
> for Groovy 5 that we match 0 or 1-arg SAMs more closely that say a 2-arg SAM
> for such a Closure.
> The impact of this is that there will be less ambiguity errors (or
> conversely, less places where we need to cast to get the correct method). It
> obviously doesn't help if there are both 0 and 1-arg options available, where
> casting would still be required.
> Examples:
> {code}
> def method1(IntUnaryOperator unary) { '1a' }
> def method1(IntBinaryOperator binary) { '1b' }
> // unchanged behavior
> assert method1{ a -> } == '1a'
> assert method1{ a, b -> } == '1b'
> assert method1({ } as IntUnaryOperator) == '1a'
> assert method1({ } as IntBinaryOperator) == '1b'
> // proposed change: implicit arg will match Unary over Binary since Unary is
> the only match for 0 or 1 args
> assert method1{ } == '1a'
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
