# Does splatting create a shallow copy?

**URL:** https://discourse.julialang.org/t/does-splatting-create-a-shallow-copy/55566
**Category:** General Usage
**Created:** [February 18, 2021, 6:25pm UTC](https://discourse.julialang.org/t/does-splatting-create-a-shallow-copy/55566 "2021-02-18T18:25:50Z")
**Posts on this page:** 1
**Showing post:** 8

<div class="post-metadata">

### Author: ![Henrique\_Becker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/henrique_becker/32/15443_2.png) [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [February 19, 2021, 3:53pm UTC](https://discourse.julialang.org/t/does-splatting-create-a-shallow-copy/55566/8 "2021-02-19T15:53:31Z")

</div>

> [@anon60034542](#):
>
> Bare with me here cause I’m still learning 😀. I want to make sure I have a good understanding of `copy()` before I start using it.

A wise decision.

> [@anon60034542](#):
>
> When you have a simple structure  
> …  
> However, if the structure is more complicated for example

In practice things happens as you describe, but there is also a fundamental misunderstanding here: `copy` is blind to the inner elements, it does not take different decisions based on the type of the inner elements, it always do the same thing: copying a reference to the element.

“But what about `Int`s”, you may say, “they are copied by value” or yet, “changes I make to them do not reflect in the original array”. To that I have two answers:

1. “changes I make to them do not reflect in the original array” – You never make changes to an `Int`s object, they are immutable. You cannot take `5` and modify it. You can have an `Int` field/position and modify which `Int` object is inside it, but the field/position itself is a property of the container not of the object; the object itself is never modified. This confusion arises of the old: `binding`/`label`/`reference` versus `variable`/`box`/`memory-block`.
2. “they are copied by value” – They may, or they may not. This is just a compiler optimization. And this is not just for `Int`s but for any immutable object, if the compiler deems the object “too large to be copied” or is able to perceive it will be copied to a lot of places, it can instead copy a reference instead. As the object is immutable, it is impossible to the user to see a semantic difference: the user cannot change the object to see a change in many places. You can sometimes see a performance difference however: [see this very interesting case in which the compiler is able to do an unexpectedly smart deduction](https://discourse.julialang.org/t/how-come-this-is-non-allocating/55216/4).

I think we are at the `binding`/`label`/`reference` versus `variable`/`box`/`memory-block` again. If you can forget memory layout for a moment, the best way to see it is that `copy` over a container always duplicate the container itself but the container is **always** a container of `binding`s/`label`s/`reference`s. Consequently, if you `copy`

---

_[View the full topic](https://discourse.julialang.org/t/does-splatting-create-a-shallow-copy/55566)._