[
https://issues.apache.org/jira/browse/GROOVY-10219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17413213#comment-17413213
]
Eric Milles commented on GROOVY-10219:
--------------------------------------
The dynamic case works thanks to late binding. The value of {{cl}} is used to
determine what "delegate" means during execution. It could be different if
{{cl}} is changed for each execution of the closure.
There is certainly a constraint here for either the compiler or the editor. If
the compiler was to type check based on the end value of {{cl}} it would need
to perform more than one pass over the AST in case of closures or lambdas. If
the editor wishes to provide inference feedback to the user based on the AST
metadata that STC adds, it can only see what is there after the entire AST has
been consumed.
For eclipse code completion, the STC type is used when available [1]. In this
case, {{cl}} the variable expression has no STC metadata; its accessed variable
does, but that should not be used IMO.
[1]
https://github.com/groovy/groovy-eclipse/blob/master/ide/org.codehaus.groovy.eclipse.core/src/org/codehaus/groovy/eclipse/core/inference/STCTypeLookup.java#L61
> Closure type for local var is inferred, but unavailable to Closure's contents
> -----------------------------------------------------------------------------
>
> Key: GROOVY-10219
> URL: https://issues.apache.org/jira/browse/GROOVY-10219
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
> Reporter: Svatopluk Dedic
> Assignee: Eric Milles
> Priority: Major
>
> {code:java}
> @groovy.transform.CompileStatic
> class A {
> def err() {
> // should be inferenced to Closure
> def cl
> cl = {
> assert cl.delegate != null; // This errors out
> };
> assert cl.delegate != null; // This works OK
> }
> }
> new A().err()
> {code}
> It appears as the closure's type is stored/inferred only after the type
> checker finishes the Closure's AST subtree. But regardless of possible
> parameters (and their types) and/or return type, the whole expression is
> always assignable to Closure, so the Closure's contents should be able to
> work with its delegate/owner properties.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
