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) — so it can *prove* the answer
automatically. Dynamic
compilation doesn't resolve those names at compile time, so it
cannot prove it — 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 PM Jochen Theodorou <[email protected]> wrote:
>
>
>
> On 7/15/26 06:01, Paul King wrote:
> [...]
> > Dynamic packing
> > stays annotation-only (@PackedClosures) regardless — it cannot be
> > proven sound without types — 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 = {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
>
