```
inner(pc) = sum(pc)
outer(pc,σ) = prod(pc,σ)
tst = let
pc = rand(3,10)
σ = 2.0
tst() = losses = outer(inner(pc), σ)
end
```

What do you want to achieve here?

Isn’t just

```
tst(pc,σ) = outer(inner(pc),σ)
tst(rand(3,10), 2.0))
```

what you want there?

I’m just trying to come up with a contrived example that illustrates the problem in much more complicated code. I don’t understand the type instability with closures. I will see if i can construct a closer example.

If the variable that is closed-over is a global variable, not constant and not typed, then the closure will be type unstable. For example:

```
julia> a = 1.0
1.0
julia> f(x) = x - a
f (generic function with 1 method)
julia> @code_warntype(f(1.0))
MethodInstance for f(::Float64)
from f(x) in Main at REPL[5]:1
Arguments
#self#::Core.Const(f)
x::Float64
Body::Any
1 ─ %1 = (x - Main.a)::Any
└── return %1
```

That’s type unstable because the type of `a`

cannot be known. Also there is performance of captured variables in closures · Issue #15276 · JuliaLang/julia · GitHub, which is a long standing difficulty on using closures in many contexts.

This is type unstable,

```
pc = problem.cspond
σ = 4.0
# pc = pc, σ = σ
calc_loss = let
losses = Vector{Float64}(undef, length(pc))
calc_loss(F::FundamentalMatrix)::Vector{Float64} = losses .= cauchy_ρ.(fund_mat_signed_sampson_dist.(pc, Ref(F)), σ)
end
```

while this is type stable,

```
pc = problem.cspond
σ = 4.0
calc_loss = let pc = pc, σ = σ
losses = Vector{Float64}(undef, length(pc))
calc_loss(F::FundamentalMatrix)::Vector{Float64} = losses .= cauchy_ρ.(fund_mat_signed_sampson_dist.(pc, Ref(F)), σ)
end
```

I guess it’s related to the bug you referenced. I tried to use FastClosures, but I could not understand how to use it in this context.

If you are running that in the global scope, it will be type unstable just because `pc`

and `sigma`

are non-constant globals in the first case, and aren’t in the second.

Otherwise it is probably related to that bug.

no, pc and sigma are declared in the context of a function. it was a bit hard to construct a minimal working example here.

Then its the bug. I think using the assignments on the let are effectively the way to handle that.

I don’t understand why that fixes things. But also isn’t there a fastclosure package that is supposed to fix this? how do you use the macro?

I think there it would be just:

```
@closure calc_loss(F::FundamentalMatrix)::Vector{Float64} = losses .= cauchy_ρ.(fund_mat_signed_sampson_dist.(pc, Ref(F)), σ)
```

(replacing the let block, with the definition of losses, pc and sigma outside there.

I think i tried that and there was some compile error. Ok, I will take a look again. This bug is a big problem because optimization code often needs closure for reasonable syntax.

The problem is more when modifying the closed over variables. In your case the `losses`

variable is being closed over and modified. Maybe it is more clear if you define it inside the `calc_loss`

function, or if you pass it as a parameter as well.

(but yes, it is an annoying bug)

if I make losses an lvalue, is it possible to avoid a temporary array created inside calc_loss, in other words,

```
losses .= calc_loss(...)
```

I get a bit confused if the compiler can optimize this.

only if losses is a small static array, otherwise it can’t.

The other way (which I like most, is make `calc_losses`

a callable object that carries the buffer. Something like:

```
julia> struct CalcLosses
losses::Vector{Float64}
a::Float64
end
julia> (c::CalcLosses)(x::Vector{Float64}) = c.losses .= c.a .* x
julia> calc_losses = CalcLosses(ones(10), 2.0)
CalcLosses([1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0], 2.0)
julia> calc_losses(rand(10))
10-element Vector{Float64}:
0.48654014606839024
0.7925405464740596
1.0971990327794896
1.1542839828629714
0.29858374238632046
0.029375859407316796
1.6187913231998186
0.056574918959434894
1.0338038499413729
1.2413140671199132
```

I don’t know if every type of optimization interface can handle that, though.

```
(c::CalcLosses)(x::Vector{Float64}) = c.losses .= c.a .* x
```

you’ve lost me here Can you explain this syntax?

Functions in julia aren’t the only things that can have methods. In fact, functions are just a special case of something called “callable structs”. The idea here, is that you can treat the struct `CalcLosses`

as a function itself, but that function stores data it can reference.

So when they write

```
(c::CalcLosses)(x::Vector{Float64}) = c.losses .= c.a .* x
```

it’s saying that for any `c`

whose type is `CalcLosses`

, you can write `c(x)`

where `x`

is of type `Vector{Float64}`

and it will compute `c.losses .= c.a .* x`

.

But this functionality seems very similar to what can be achieved with closures. Besides avoiding the compiler bug or limitation, what is the advantage of this construction?

I didn’t say it was different. In fact, this is exactly how closures work. The problem is just that closures can’t assume that various things are type stable, so you essentially end up with a struct that looks like

```
struct CalcLosses
losses::Any
a::Any
end
```

or something if it can’t assume that `losses`

and `a`

dont’ change type.

Counterintuitively, `losses`

is an rvalue here because this expression lowers to a call to `Base.materialize!(losses, ...)`

. You can confirm this like so:

```
julia> _ = [1,2,3];
julia> _ .= [1,2,3];
ERROR: syntax: all-underscore identifier used as rvalue
```

It’s similar to how in the expression `x[1:2] = 3:4`

, `x`

is an rvalue because the expression is lowered to `setindex!(x, 3:4, 1:2)`

. Not to worry, this is a good thing; because it’s an rvalue, the identifier is not reassigned.

However, from your description above, the actual type instability is likely occuring because `pc`

and/or `σ`

are assigned to more than once in the parent scope, making it so that `calc_loss`

doesn’t know what value to assume when it’s called, so it boxes them. This is why the `let`

block trick works: it captures a snapshot of their values and makes it so the closure can access only the value at that specific point.