# Type Instability with AbstractArray

**URL:** <https://discourse.julialang.org/t/type-instability-with-abstractarray/37074>\
**Category:** General Usage\
**Created:** [April 5, 2020, 8:44pm UTC](https://discourse.julialang.org/t/type-instability-with-abstractarray/37074 "2020-04-05T20:44:18Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![gideonsimpson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gideonsimpson/32/1928_2.png) [@gideonsimpson](https://discourse.julialang.org/u/gideonsimpson)\
**Post date:** [April 5, 2020, 8:44pm UTC](https://discourse.julialang.org/t/type-instability-with-abstractarray/37074/1 "2020-04-05T20:44:18Z")

</div>

Consider the following code:

```julia
using Random

mutable struct mystate{Tq}
    x::AbstractArray{Tq,1}
end

function update!(state::mystate{Tq}) where Tq
    @. state.x[1] = 0.5 * state.x[2] + randn();
    @. state.x[2] = -0.5 * state.x[1] + randn();
    state
end

function prep(x0::AbstractArray{Tq,1}) where Tq

    state = mystate(x0);
    return state
    # return ar1(xdata, 100);
end

function integrate_path(x0::AbstractArray{Tq,1}, n_iters::Int) where Tq

    state= prep(x0);
    for j in 1:n_iters
        update!(state)
    end
    return state.x
end

X0 = [[1.],[-2.]];

Random.seed!(100);
# ar1(x0,100)
@code_warntype integrate_path(X0, 100)

```

On my v1.4 installation, this generates a type instability:

```julia
Variables
  #self#::Core.Compiler.Const(integrate_path, false)
  x0::Array{Array{Float64,1},1}
  n_iters::Int64
  state::mystate{Array{Float64,1}}
  @_5::Union{Nothing, Tuple{Int64,Int64}}
  j::Int64

Body::AbstractArray{Array{Float64,1},1}
1 ─ (state = Main.prep(x0))
│ %2 = (1:n_iters)::Core.Compiler.PartialStruct(UnitRange{Int64}, Any[Core.Compiler.Const(1, false), Int64])
│ (@_5 = Base.iterate(%2))
│ %4 = (@_5 === nothing)::Bool
│ %5 = Base.not_int(%4)::Bool
└── goto #4 if not %5
2 ┄ %7 = @_5::Tuple{Int64,Int64}::Tuple{Int64,Int64}
│ (j = Core.getfield(%7, 1))
│ %9 = Core.getfield(%7, 2)::Int64
│ Main.update!(state)
│ (@_5 = Base.iterate(%2, %9))
│ %12 = (@_5 === nothing)::Bool
│ %13 = Base.not_int(%12)::Bool
└── goto #4 if not %13
3 ─ goto #2
4 ┄ %16 = Base.getproperty(state, :x)::AbstractArray{Array{Float64,1},1}
└── return %16

```

where, in my terminal, the `AbstractArray{Array{Float64,1},1}` appear in red (which I am interpreting as bad). If I switch to `Array{Tq,1}`, the instability disappears. Questions:

1. Is this red actually bad from either a style/perfomance point of view?
2. What am I losing by just using `Array{Tq,1}` instead? The reason I had wanted it to be more general was so that the actual code I am using could handle things like `SharedArrays`.
3. Is there a way to avoid this type instability but maintain the flexibility of `AbstractArray`?
4. Any other recommendations?

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [April 5, 2020, 8:48pm UTC](https://discourse.julialang.org/t/type-instability-with-abstractarray/37074/2 "2020-04-05T20:48:51Z")

</div>

> [@gideonsimpson](#):
>
> `mutable struct mystate{Tq} x::AbstractArray{Tq,1} end`

Don’t use abstract types for struct fields, as [explained in the manual](https://docs.julialang.org/en/v1/manual/performance-tips/#man-performance-abstract-container-1). If you want to support any type of `AbstractArray` here, then you can do:

```julia
mutable struct mystate{Tq,Tv<:AbstractVector{Tq}}
    x::Tv
end

```

or simply

```julia
mutable struct mystate{Tv<:AbstractVector}
    x::Tv
end

```

(`AbstractVector{T}` is just a convenient synonym for `AbstractArray{T,1}`.)

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [April 5, 2020, 11:12pm UTC](https://discourse.julialang.org/t/type-instability-with-abstractarray/37074/3 "2020-04-05T23:12:46Z")

</div>

Also, there is no obvious reason for you to use a `mutable struct` in your particular example. As long as the field that you want to modify is mutable, the parent struct does not have to be mutable.

Furthermore, there is a strong convention to use CamelCase for type names, that is, `MyState` instead of `mystate`.