I am trying to resolve a type stability problem in a function where some local variables are showing up as the type Core.Box when I run @code_warntype. I’ve narrowed the cause to where I use a comprehension or generator with those variables as inputs, and those variables can be modified later in the…

This is so confusing for me too: julia> function box() x::Float64 = rand() y = 0.0 if x > 0 y2 = mean((round(x) for _ in 1:100)) end x = 1.0 return(x, 1) end box (generic function with 1 method) julia> …

I believe this is the famous variable captured in closure bug.

Performance Tips · The Julia Language has some more information about this particular problem.

Yeah but in this case the type annotation does not help. I’m aware of the captured variable bug but it’s kinda annoying that it’s so re-occurring. Here it seems that the comprehension captures x? What helps is. function box_fixed() x::Float64 = rand() y = 0.0 let x=x i…

Correct, Meta.@lower is your friend here: julia> Meta.@lower mean(x for _ in 1:100) :($(Expr(:thunk, CodeInfo( @ none within `top-level scope` 1 ─ $(Expr(:thunk, CodeInfo( @ none within `top-level scope` 1 ─ global var"#5#6" │ const var"#5#6" │ %3 = Core._structtype(Main…

There is no indication that a closure is created when you write a comprehension, so people don’t know to look for one when trying to hunt down the source of the box. This is certainly part of my confusion. I was trying to comprehend (no pun intended) how the documentation linked by @Zentrik relat…

Well, that certainly feels awkward and counterintuitive. I’ll stick to separating out the function. It’s a shame because comprehensions, generators, map, etc. are all such workhorses.

I do wonder whether we could fix this by lowering to opaque closures. this is a case where we make the closure and immediately execute it, so making a closure does lose information.

[image] Oscar_Smith: I do wonder whether we could fix this by lowering to opaque closures. this is a case where we make the closure and immediately execute it, … Unless, of course, you keep the generator around: function box() x::Float64 = rand() if x > 0 y = (round(x) for _ …

[image] ToucheSir: There is no indication that a closure is created when you write a comprehension, so people don’t know to look for one when trying to hunt down the source of the box. [image] roflmaostc: Here it seems that the comprehension captures x? The scoping rules say that compr…

Help understand boxing

General Usage Performance

Topic		Replies	Views
RFC: Some Ideas to Tackle #15276 - performance of captured variables in closures Internals & Design inference , type-stability , corebox	65	5037	February 16, 2024
Language restriction to solve 15276? Internals & Design	48	4186	May 11, 2018
Weird type instability General Usage question , performance	8	1134	January 5, 2018
Call FastClosures.jl `@closure` in Array Comprehensions? Internals & Design performance , closure , corebox , comprehension	2	1079	February 3, 2023
Surprising slowdown from using array comprehension Performance	8	346	June 4, 2025

Help understand boxing

Related topics