# How to determine mutability at compile time

**URL:** <https://discourse.julialang.org/t/how-to-determine-mutability-at-compile-time/4957>\
**Category:** General Usage\
**Created:** [July 19, 2017, 9:28pm UTC](https://discourse.julialang.org/t/how-to-determine-mutability-at-compile-time/4957 "2017-07-19T21:28:17Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![danielmatz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/danielmatz/32/2285_2.png) [@danielmatz](https://discourse.julialang.org/u/danielmatz)\
**Post date:** [July 19, 2017, 9:28pm UTC](https://discourse.julialang.org/t/how-to-determine-mutability-at-compile-time/4957/1 "2017-07-19T21:28:17Z")

</div>

I’m trying to write a function that will accept an argument that implements the `AbstractArray` interface. I’m finding that I need to write one implementation for mutable `AbstractArray`s and another for immutable `AbstractArray`s. I see the `isimmutable` function, but after experimenting, it seems that it doesn’t get optimized away at compile time as I hoped it would.

What is the right way to have separate implementations for mutable and immutable objects?

Thank you!

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [July 19, 2017, 9:48pm UTC](https://discourse.julialang.org/t/how-to-determine-mutability-at-compile-time/4957/2 "2017-07-19T21:48:27Z")

</div>

mutable object can be read only array and immutable object can be mutable arrays so you must not use the mutability of the object to decide if the array is mutable. You should not define an API that conditionally mutate an input array so you shouldn’t need to do this.

---

<div class="post-metadata">

**Author:** ![adamslc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adamslc/32/3452_2.png) [@adamslc](https://discourse.julialang.org/u/adamslc)\
**Post date:** [July 19, 2017, 10:07pm UTC](https://discourse.julialang.org/t/how-to-determine-mutability-at-compile-time/4957/3 "2017-07-19T22:07:43Z")

</div>

In Julia, it is good practice to append an exclamation point to any function that mutates its arguments. This means that your use case is usually solved by writing two functions `foo` and `foo!`. Then your user can decide if they want to use the mutating or non-mutating version of your function.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [July 20, 2017, 2:38am UTC](https://discourse.julialang.org/t/how-to-determine-mutability-at-compile-time/4957/4 "2017-07-20T02:38:20Z")

</div>

For now just assume that they will be `<:SArray` if they are immutable arrays.

> <https://github.com/JuliaLang/julia/issues/21869>
>
> Using different types of immutable indexable types can be useful, but this is ve…ry difficult (if not impossible?) to handle with generic code right now. For example, an \`SArray\` from StaticVectors.jl is \`\<:AbstractArray\`. Many times you may want to have separate code paths for abstract arrays, like:
> 
> \`\`\`julia
> if typeof(a) \<: AbstractArray
> a .= b .+ c
> else
> a = b+c
> end
> \`\`\`
> 
> However, there is currently no way to distinguish between immutable and mutable collections. Note that this exact case would actually be solved by
> 
> https://github.com/JuliaLang/julia/issues/19992
> 
> but that is just a bandaid for a single case. Another case for example would be choosing between \`fill!\`ing a vector or creating a new one matching the immutable array type with \`zeros\`. I'm not sure Julia can always automate this choice in every case, and so the ability to distinguish between these classes of types is crucial. Without a Base abstract type, this requires a dependency for each array type you want to support like this. A simple \`AbstractImmtableArray{T,N} \<: AbstractArray{T,N}\` could handle this.

> [@yuyichao](#):
>
> You should not define an API that conditionally mutate an input array so you shouldn’t need to do this.

No. How else do you write a fast algorithm on arrays that works with both StaticArrays and regular arrays? You might just be using the mutation internally, but it still matters. If you don’t care about performance, sure simply always do the mutating form. Or you can specialize only on `Array`, but that leaves out most other `AbstractArray` types which are mutable. Or you do `y = internally_mutable_f(x)` and `y = internally_immutable_f(x)`, i.e. let it be user choice (which is what DiffEq is silently doing), but it’s pretty clear this should be using dispatch and we are just missing a feature…

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [July 20, 2017, 4:35am UTC](https://discourse.julialang.org/t/how-to-determine-mutability-at-compile-time/4957/5 "2017-07-20T04:35:05Z")

</div>

> [@ChrisRackauckas](#):
>
> For now just assume that they will be \<:SArray if they are immutable arrays.

That will definately not work, there are lots of array types in base that do not satisfy this.

> [@ChrisRackauckas](#):
>
> let it be user choice

Yes, that sounds much better.

> [@ChrisRackauckas](#):
>
> How else do you write a fast algorithm on arrays that works with both StaticArrays and regular arrays?

> [@ChrisRackauckas](#):
>
> we are just missing a feature

The missing feature is to be able to pass a reference of a stack reference to a function. You should be able to just work on the mutable container since that’ll be how it’s mutated and a much more efficiently way to pass it around anyway.