### Author:  [@oxinabox](https://discourse.julialang.org/u/oxinabox)
#### Post date: [September 3, 2024, 3:25pm UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/3 "2024-09-03T15:25:33Z")
Fix1 and Fix2 are not related to the accidental boxing thing which is in general the main performance issue with closures and why people use let blocks or FastClosures.jl.
Any anon function that can be written to use Fix1 or Fix2 is pretty much certain not to be possible to write in a way that runs into that issue.
I suspect the SciML style-guide suggests avoiding them either
- Purely as a stylistic preference: that it was felt to be easier to read;
- or as a microoptimization on compile times. Since identical anon functions do still compile sperately but `Fix1` and `Fix2` uses do not
But you would need to talk to author of that rule to know
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [September 3, 2024, 3:32pm UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/4 "2024-09-03T15:32:12Z")
This is a confused post.
> [@Deduction42](#):
>
> I thought most of these performance issues were fixed with v1.0
AFAIK some cases are fixed with each new Julia release, but a complete fix will probably only happen when the lowering gets rewritten in Julia, @c42f. Relevant issue:
>
>
> \`\`\` jl
> using Images: realtype
>
> function ifi{T\<:Real,K,N}(img::AbstractArray{T,N}…, kern::AbstractArray{K,N}, border::AbstractString, value)
> if border == "circular" && size(img) == size(kern)
> out = real(ifftshift(ifft(fft(img).\*fft(kern))))
> elseif border != "inner"
> prepad = \[div(size(kern,i)-1, 2) for i = 1:N\]
> postpad = \[div(size(kern,i), 2) for i = 1:N\]
> fullpad = \[nextprod(\[2,3\], size(img,i) + prepad\[i\] + postpad\[i\]) - size(img, i) - prepad\[i\] for i = 1:N\]
> A = padarray(img, prepad, fullpad, border, convert(T, value))
> krn = zeros(typeof(one(T)\*one(K)), size(A))
> indexesK = ntuple(d-\>\[size(krn,d)-prepad\[d\]+1:size(krn,d);1:size(kern,d)-prepad\[d\]\], N)::NTuple{N,Vector{Int}}
> AF = ifft(fft(A).\*fft(krn))
> out = Array(realtype(eltype(AF)), size(img))
> end
> out
> end
> \`\`\`
>
> Test:
>
> \`\`\` jl
> julia\> @code\_warntype ifi(rand(3,3), rand(3,3), "replicate", 0)
> Variables:
> #self#::#ifi
> img::Array{Float64,2}
> kern::Array{Float64,2}
> border::ASCIIString
> value::Int64
> prepad::Box
> ...
> \`\`\`
>
> Now comment out the \`indexesK = ...\` line (the output of which is not used at all). Suddenly \`prepad\` is inferred as \`Array{Int, 1}\`.
> [@Deduction42](#):
>
> Fix1/Fix2 aren’t exported from base
This is of no significance. It’s just polite not to export from `Base`, so as to prevent name space pollution, and prevent breaking existing code.
---
### Author:  [@CameronBieganek](https://discourse.julialang.org/u/CameronBieganek)
#### Post date: [September 3, 2024, 4:23pm UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/5 "2024-09-03T16:23:56Z")
> [@oxinabox](#):
>
> I suspect the SciML style-guide suggests avoiding them either
>
> - Purely as a stylistic preference: that it was felt to be easier to read;
> - or as a microoptimization on compile times. Since identical anon functions do still compile sperately but `Fix1` and `Fix2` uses do not
I believe SciML folks have expressed on this forum the opinion that closures are simply too dangerous (performance-wise) to ever use, so they recommend never using them. (I personally think that viewpoint is extreme.)
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [September 3, 2024, 5:20pm UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/6 "2024-09-03T17:20:28Z")
I don’t see any problem in using either of them, both have benefits.
Fix1/Fix2/Fix:
- can dispatch other functions on them, eg:
```julia
julia> using InverseFunctions
# impossible with anonymous function:
julia> inverse(Base.Fix2(+, 123)) |> dump
Base.Fix2{typeof(-), Int64}(-, 123) (function of type Base.Fix2{typeof(-), Int64})
f: - (function of type typeof(-))
x: Int64 123
```
- somewhat faster to compile
Anonymous function:
- more general
- potentially faster to execute (due to constprop)
---
### Author:  [@greatpet](https://discourse.julialang.org/u/greatpet)
#### Post date: [September 3, 2024, 9:21pm UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/7 "2024-09-03T21:21:23Z")
> [@oxinabox](#):
>
> or as a microoptimization on compile times.
Or maybe it’s needed to enable static compilation? (Even though this is a niche use case of Julia.)
---
### Author:  [@Deduction42](https://discourse.julialang.org/u/Deduction42)
#### Post date: [September 4, 2024, 2:10am UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/8 "2024-09-04T02:10:19Z")
Yes, this is a confused post, because I was genuinely confused. Thanks everyone for the input.
---
### Author:  [@danielwe](https://discourse.julialang.org/u/danielwe)
#### Post date: [September 4, 2024, 3:21am UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/9 "2024-09-04T03:21:09Z")
> [@oxinabox](#):
>
> Any anon function that can be written to use Fix1 or Fix2 is pretty much certain not to be possible to write in a way that runs into that issue.
Is that true? Take the pitfall example from the docs; the boxing can be eliminated by replacing the closure with `Base.Fix2`, improving performance by a factor of 7. To my understanding, the key issue is whether the captured variable is reassigned at any point in the scope from which it’s captured, which is a property of the outer function, not the closure.
```julia-repl
julia> function abmult(r::Int)
if r < 0
r = -r
end
f = x -> x * r
return f
end;
julia> function abmultfix(r::Int)
if r < 0
r = -r
end
f = Base.Fix2(*, r)
return f
end;
julia> f = abmult(4);
julia> ffix = abmultfix(4);
julia> @code_warntype f(2) # Boxed, type unstable
MethodInstance for (::var"#1#2")(::Int64)
from (::var"#1#2")(x) @ Main REPL[1]:5
Arguments
#self#::var"#1#2"
x::Int64
Locals
r::Union{}
Body::Any
1 ─ %1 = Core.getfield(#self#, :r)::Core.Box
│ %2 = Core.isdefined(%1, :contents)::Bool
└── goto #3 if not %2
2 ─ goto #4
3 ─ Core.NewvarNode(:(r))
└── r
4 ┄ %7 = Core.getfield(%1, :contents)::Any
│ %8 = (x * %7)::Any
└── return %8
julia> @code_warntype ffix(2) # Fix2, type stable
MethodInstance for (::Base.Fix2{typeof(*), Int64})(::Int64)
from (f::Base.Fix2)(y) @ Base operators.jl:1135
Arguments
f::Base.Fix2{typeof(*), Int64}
y::Int64
Body::Int64
1 ─ %1 = Base.getproperty(f, :f)::Core.Const(*)
│ %2 = Base.getproperty(f, :x)::Int64
│ %3 = (%1)(y, %2)::Int64
└── return %3
julia> using BenchmarkTools
julia> @btime $f(2);
35.534 ns (0 allocations: 0 bytes)
julia> @btime $ffix(2);
4.780 ns (0 allocations: 0 bytes)
```
---
### Author:  [@c42f](https://discourse.julialang.org/u/c42f)
#### Post date: [September 4, 2024, 5:25am UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/11 "2024-09-04T05:25:54Z")
> [@Deduction42](#):
>
> Yes, this is a confused post, because I was genuinely confused. Thanks everyone for the input.
It’s so fine to be confused and to ask questions. That is what this forum is for ❤
(Not only that, but this particular subject is just very confusing in general. Not a lot of people appreciate just how difficult fixing this is! Even FastClosures.jl has subtly broken semantics, I think, but I’ve not worked on it for a long while.)
I’m occasionally concerned people seem to think I know exactly how to fix the general problem but noope, I do not 😆
I have a few little ideas, but IIUC lowering just doesn’t have enough information for this. Perhaps with cooperation between both lowering and the optimizer/type inference we can get close to really fixing this, eventually.
I expect to be rewriting the corresponding part of lowering in November-ish so I’ll have a better appreciation for the challenges at that point.
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [September 4, 2024, 7:00am UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/12 "2024-09-04T07:00:27Z")
> [@Deduction42](#):
>
> Yes, this is a confused post, because I was genuinely confused.
Sorry, I was rude.
---
### Author:  [@oxinabox](https://discourse.julialang.org/u/oxinabox)
#### Post date: [September 6, 2024, 1:09pm UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/13 "2024-09-06T13:09:38Z")
oof, I forgot about that detail.
you are correct
---
### Author:  [@Deduction42](https://discourse.julialang.org/u/Deduction42)
#### Post date: [September 6, 2024, 2:39pm UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/14 "2024-09-06T14:39:21Z")
THIS was what really confused me. How does Fix2(…) solve the boxed variable problem? I tried something like deepcopy. If you copy “r” you shouldn’t need it anymore, copies of “r” aren’t reassigned. But it still boxes r.
```julia
julia> function abmult(r::Int)
if r < 0
r = -r
end
f(x) = deepcopy(r)*x
return f
end
abmult (generic function with 1 method)
julia> f = abmult(4); @code_warntype f(2)
MethodInstance for f(::Int64)
from f(x) @ Main REPL[4]:5
Arguments
#self#::typeof(f)
x::Int64
Locals
r::Union{}
Body::Any
1 ─ %1 = Core.getfield(#self#, :r)::Core.Box
│ %2 = Core.isdefined(%1, :contents)::Bool
└── goto #3 if not %2
2 ─ goto #4
3 ─ Core.NewvarNode(:(r))
└── r
4 ┄ %7 = Core.getfield(%1, :contents)::Any
│ %8 = Main.deepcopy(%7)::Any
│ %9 = (%8 * x)::Any
└── return %9
```
---
### Author:  [@Deduction42](https://discourse.julialang.org/u/Deduction42)
#### Post date: [September 6, 2024, 2:45pm UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/15 "2024-09-06T14:45:42Z")
Oh I just realized deepcopy still gets applied every time that function runs. So if I just create another variable and add it to the expression, boxing doesn’t happen. THAT’s how Fix2 solves the problem.
```julia
julia> function abmult(r::Int)
if r < 0
r = -r
end
r1 = deepcopy(r); f(x) = r1*x
return f
end
abmult (generic function with 1 method)
julia> f = abmult(4); @code_warntype f(2)
MethodInstance for (::var"#f#3"{Int64})(::Int64)
from (::var"#f#3")(x) @ Main REPL[7]:5
Arguments
#self#::var"#f#3"{Int64}
x::Int64
Body::Int64
1 ─ %1 = Core.getfield(#self#, :r1)::Int64
│ %2 = (%1 * x)::Int64
└── return %2
```
So I guess that means if you’re working with closures, don’t capture a variable that gets reassigned to (or at least be VERY careful about it). I’m actually very careful about reassigning variables anyway because I got burned by type instabilities before. I can see why you wouldn’t want to capture something like this.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [June 6, 2025, 12:49pm UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/16 "2025-06-06T12:49:49Z")
Hope it is OK to revive this topic with a question instead of opening another one.
If there is no assignment, just a chain of nested function calls, is it OK to use closures then?
Or, from a practical perspective, if tooling (JET, profiling etc) does not show type instability, then one is not bitten by this issue (whatever the issue is)?
I found this topic because I got a PR to a repo of mine from a person who refers to the [SciML style guide about avoiding closures](https://docs.sciml.ai/SciMLStyle/stable/#Closures-should-be-avoided-whenever-possible). The whole point of the PR is to replace all closures with `Fix`whatever.
As far as I could discern there is no issue with the particular pieces of code (which I will not link here, as I don’t want to single out the submitter), the justification is simply “closures should be avoided because SciML says so”. I understand [#15276](https://github.com/JuliaLang/julia/issues/15276) and it definitely does not apply. Is there any other issue which highlights a problem with closures? I am completely baffled by the lengths some people go to to avoid them.
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [June 6, 2025, 3:58pm UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/17 "2025-06-06T15:58:17Z")
Closures are a great core feature of Julia! It’s fine for some people/organizations to decide they want to avoid them, but generally closures are extremely common in code. They also often are more performant than Fix1/2.
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [June 6, 2025, 10:31pm UTC](https://discourse.julialang.org/t/state-of-closures-fix1-fix2/118997/18 "2025-06-06T22:31:51Z")
Agreeing with both of you, closures are awesome. However, using named stuff, like `Fix1` or `identity` or `Returns`, when possible, seems like good style. A justification is that each new closure has new identity and the compiler has to parse and compile it again, even if it already compiled other equivalent closures. This:
```julia-repl
julia> (x -> 3) === (x -> 3)
false
julia> Returns(3) === Returns(3)
true
```