# How come this is non-allocating?

**URL:** <https://discourse.julialang.org/t/how-come-this-is-non-allocating/55216>\
**Category:** New to Julia\
**Created:** [February 13, 2021, 5:12pm UTC](https://discourse.julialang.org/t/how-come-this-is-non-allocating/55216 "2021-02-13T17:12:18Z")\
**Posts on this page:** 1\
**Showing post:** 4

<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:** [February 13, 2021, 7:29pm UTC](https://discourse.julialang.org/t/how-come-this-is-non-allocating/55216/4 "2021-02-13T19:29:25Z")

</div>

Since `eltype(v)` is abstract (and not a small union), the underlying data is stored as an array of pointers to tuples. And since tuples are immutable, when you assign them all to `(1,1,1)` the compiler is allowed to store the same pointer for every element:

```julia
julia> v = [isodd(i) ? (0,0) : (0,0,0) for i in 1:5];

julia> mutate_vec!(v)

julia> p = unsafe_wrap(Array, Ptr{Ptr{Int}}(pointer(v)), length(v))
5-element Array{Ptr{Int64},1}:
 Ptr{Int64} @0x000000011655e470
 Ptr{Int64} @0x000000011655e470
 Ptr{Int64} @0x000000011655e470
 Ptr{Int64} @0x000000011655e470
 Ptr{Int64} @0x000000011655e470

julia> unsafe_wrap(Array, p[1], 3)
3-element Array{Int64,1}:
 1
 1
 1

```

Furthermore, the compiler may not need to allocate the `(1,1,1)` tuple on the heap — since it is constant and immutable, it might just get stored in a [data segment](https://en.wikipedia.org/wiki/Data_segment) of the compiled object code.

---

_[View the full topic](https://discourse.julialang.org/t/how-come-this-is-non-allocating/55216)._