Re: some things about Closure

AI read below - I will push for further free names support.

----

You're right and my sentence was sloppy. The real split is:

  * Closure with no free names (the { x -> x+1 } class): provably
delegate-independent
    by inspection. Types irrelevant.
  * Closure WITH a free name (foo(), or a bare bar): you have to know
whether that name
    resolves to the owner (safe to bind at compile time) or could be a
delegate member
    (unsafe). @CompileStatic's type checker resolves each one and
records where it landed
    (the IMPLICIT_RECEIVER path) =E2=80=94 so it can *prove* the answer
automatically. Dynamic
    compilation doesn't resolve those names at compile time, so it
cannot prove it =E2=80=94 which
    is why the dynamic path uses the @PackedClosures trust assertion
plus the runtime
    guard for that subset.

That is the actual role of types: they let the compiler auto-*prove*
soundness for the
free-name subset. For the trivial subset there is nothing to prove.

On Wed, Jul 15, 2026 at 3:45=E2=80=AFPM Jochen Theodorou <[email protected]=
> wrote:
>
>
>
> On 7/15/26 06:01, Paul King wrote:
> [...]
> > Dynamic packing
> > stays annotation-only (@PackedClosures) regardless =E2=80=94 it cannot =
be
> > proven sound without types =E2=80=94 so the blast radius of any default=
 is:
> > statically compiled closures the compiler has proved safe, with the
> > escape analysis already declining the risky shapes (field-assigned DSL
> > blocks like Grails constraints never pack, by construction).
>
> I think I missed something. cl =3D {x->x+1} cannot be a PackedClosure? I
> am pretty sure there are a lot of cases for them. And the point I am
> really missing is I guess: in what way are types a required deciding
> factor of if something can be a PackedClosure or not?
>
> bye Jochen
>