Why are returned types different in comprehension over an empty range if called from a function vs top level?

General Usage
, ,
1 
julia> using ApproxFun

julia> rs = Jacobi(5,4);

julia> d = domain(rs);

julia> Sf = JacobiWeight(0,2,ConstantSpace(d));

julia> using ApproxFun.ApproxFunSingularities: jacobiweight

julia> using ApproxFun.ApproxFunBase: ConcreteMultiplication

julia> min(rs.b, Sf.β)-1:-1:1 # empty range
-1:-1:0

julia> [ConcreteMultiplication(jacobiweight(1,0,d), Jacobi(rs.b-i,rs.a,d)) for i in min(rs.b, Sf.β)-1:-1:1]
Any[]

julia> ((rs,Sf,d) -> [ConcreteMultiplication(jacobiweight(1,0,d), Jacobi(rs.b-i,rs.a,d)) for i in min(rs.b, Sf.β)-1:-1:1])(rs,Sf,d)
ConcreteMultiplication{JacobiWeight{ConstantSpace{ChebyshevInterval{Float64}, Float64}, ChebyshevInterval{Float64}, Float64, Int64}, Jacobi{ChebyshevInterval{Float64}, Float64, Int64}, Float64}[]

julia> VERSION
v"1.9.3"

Why are the types different? The second call is identical to the first, except this time this is placed in a function. My impression was that this might help with type-inference, but won’t change the actual types that are returned.

Edit: On second thought, perhaps the inferred type (using @default_eltype) is used to allocate the container, which is a bit unfortunate

julia> G =(ConcreteMultiplication(jacobiweight(1,0,d), Jacobi(rs.b-i,rs.a,d)) for i in min(rs.b, Sf.β)-1:-1:1)
Base.Generator{StepRange{Int64, Int64}, var"#15#16"}(var"#15#16"(), -1:-1:0)

julia> Base.@default_eltype(G)
Any

julia> ((rs,Sf,d) -> (G = (ConcreteMultiplication(jacobiweight(1,0,d), Jacobi(rs.b-i,rs.a,d)) for i in min(rs.b, Sf.β)-1:-1:1); Base.@default_eltype(G)))(rs,Sf,d)
ConcreteMultiplication{JacobiWeight{ConstantSpace{ChebyshevInterval{Float64}, Float64}, ChebyshevInterval{Float64}, Float64, Int64}, Jacobi{ChebyshevInterval{Float64}, Float64, Int64}, Float64}
1 Like
2

Comprehensions create closures, which capture variables. Creating limited scopes, such as a let block or a small function help to avoid making them mutable Any boxes that can’t infer.

You can try a let block around the comprehension as well to see if it also infers instead of Any[]. I expect it to.

3

My idea was to copy-paste existing codes to the REPL for quick testing, but looks like that won’t work

4

Yes, that’s unfortunately common when closures are involved.
Although for me, normally it is that code works in the REPL, but not inside the scope of an @testset, as the latter causes some variable defined after the closure to get captured, producing incorrect results (while later definitions of course can’t be captured in the REPL).