You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm filing this issue following a discourse thread, in case it actually is a bug. Please feel free to close it if this behavior is actually intended.
Consider the following (minimal?) example, demonstrating a type-instable application of map to the constructor of a parametric type:
julia>struct A{N}
A(::NTuple{N,Int}) where {N} =new{N}()
end
julia> t = (1,2)
(1, 2)
julia> T =typeof(t)
Tuple{Int64, Int64}
julia>using Test
julia>@inferredA(t) # the constructor is type-stable and correctly inferredA{2}()
julia>@inferredmap(A, [t]) # ... but map is not type-stable
ERROR:return type Vector{A{2}} does not match inferred return type Union{Vector{Any}, Vector{A{2}}}
julia>map(A, T[]) # indeed, on an empty vector it returns Any[]
Any[]
This behavior can be observed with Julia v1.9 as well as v1.10(beta).
As uncovered by @Seelengrab in the aforementioned discourse thread, an easy workaround consists in applying map to a standard function instead of a constructor, e.g.:
julia>@inferredmap(x->A(x), T[])
A{2}[]
I'm paraphrasing / summarizing below what they uncovered while trying to understand this; the discourse thread contains much more details.
It seems that this issue arises in Base.@default_eltype: because the applied function (A) is a type, the element type of the resulting array is determined to be A itself, even though it is a union-all type and it would be possible to infer the more precise element type (A{2} in this case). A possible fix would therefore consist in handling union-all types like regular functions, rather than special-casing them like the "regular" types. But doing this might have unintended consequences, so I'm not sure what the best way forward would be.
The text was updated successfully, but these errors were encountered:
The additional thing with this example in particular is that you can't construct an A through A{2}; it needs to go through A, so there's no way to mapA directly and have it be type stable, in the current implementation.
Hi,
I'm filing this issue following a discourse thread, in case it actually is a bug. Please feel free to close it if this behavior is actually intended.
Consider the following (minimal?) example, demonstrating a type-instable application of map to the constructor of a parametric type:
This behavior can be observed with Julia v1.9 as well as v1.10(beta).
As uncovered by @Seelengrab in the aforementioned discourse thread, an easy workaround consists in applying
map
to a standard function instead of a constructor, e.g.:I'm paraphrasing / summarizing below what they uncovered while trying to understand this; the discourse thread contains much more details.
It seems that this issue arises in
Base.@default_eltype
: because the applied function (A
) is a type, the element type of the resulting array is determined to beA
itself, even though it is a union-all type and it would be possible to infer the more precise element type (A{2}
in this case). A possible fix would therefore consist in handling union-all types like regular functions, rather than special-casing them like the "regular" types. But doing this might have unintended consequences, so I'm not sure what the best way forward would be.The text was updated successfully, but these errors were encountered: