The similar(::StaticArray, T) method returns an MArray even if called on an SArray, rightfully so since there would be no reason to call similar if you couldn't mutate the array later.
However, if !isbitstype(T), then the returned MArray is still un-mutable later because of
|
if isbitstype(T) |
|
GC.@preserve v unsafe_store!(Base.unsafe_convert(Ptr{T}, pointer_from_objref(v)), convert(T, val), i) |
|
else |
|
# This one is unsafe (#27) |
|
# unsafe_store!(Base.unsafe_convert(Ptr{Ptr{Nothing}}, pointer_from_objref(v.data)), pointer_from_objref(val), i) |
|
error("setindex!() with non-isbitstype eltype is not supported by StaticArrays. Consider using SizedArray.") |
So I think the natural thing would be for similar(::StaticArray, T) to return a SizedArray when !isbitstype(T), as basically suggested by that error message.
If people here agree, I can take a stab at a PR, but also I'm happy if someone else that's more familiar with the code-base does it (probably much faster than I can).
FWIW, this would fix FluxML/Zygote.jl#686 where this came up for me.
The
similar(::StaticArray, T)method returns anMArrayeven if called on anSArray, rightfully so since there would be no reason to callsimilarif you couldn't mutate the array later.However, if
!isbitstype(T), then the returnedMArrayis still un-mutable later because ofStaticArrays.jl/src/MArray.jl
Lines 94 to 99 in 64c64b2
So I think the natural thing would be for
similar(::StaticArray, T)to return aSizedArraywhen!isbitstype(T), as basically suggested by that error message.If people here agree, I can take a stab at a PR, but also I'm happy if someone else that's more familiar with the code-base does it (probably much faster than I can).
FWIW, this would fix FluxML/Zygote.jl#686 where this came up for me.