# How are called in Julia terminology Int64, Float64,... vs Array{T,1}, Tuple{T1,T2,...}, Set{T},

**URL:** <https://discourse.julialang.org/t/how-are-called-in-julia-terminology-int64-float64-vs-array-t-1-tuple-t1-t2-set-t/21006>\
**Category:** General Usage\
**Created:** [February 20, 2019, 10:19am UTC](https://discourse.julialang.org/t/how-are-called-in-julia-terminology-int64-float64-vs-array-t-1-tuple-t1-t2-set-t/21006 "2019-02-20T10:19:17Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 20, 2019, 12:53pm UTC](https://discourse.julialang.org/t/how-are-called-in-julia-terminology-int64-float64-vs-array-t-1-tuple-t1-t2-set-t/21006/6 "2019-02-20T12:53:20Z")

</div>

> [@sylvaticus](#):
>
> Julia by default copies only the memory address of objects

This is a common misconception. What happens is that the language is free to copy or not copy objects for which the user cannot distinguish whether copying happened. This allows the compiler various optimizations.

You may be interested in past discussions like

> [@Where exactly memory copies happen in Julia code?](https://discourse.julialang.org/t/where-exactly-memory-copies-happen-in-julia-code/5595):
>
> I have a simple question about memory management in Julia code. Coming from a C++ background with all that [rvalue reference](http://thbecker.net/articles/rvalue_references/section_01.html) madness and move semantics stuff, I got my brain damaged, and I am having a hard time trying to reason about memory management again in other languages. Consider the following cases: Case 1 I have an immutable struct that requires a decent amount of memory (e.g. mesh with vertices, edges, triangles). By using composition, I define other concepts (e.g. path): abstract ty…

> [@Assignment and argument passing semantics](https://discourse.julialang.org/t/assignment-and-argument-passing-semantics/17034):
>
> This is a short summary based on what I understood from documentation, and [this long thread](https://discourse.julialang.org/t/variable-binding-re-assignment-argument-passing-let-scope/16840) , without mixing in (much of) scope rules, or any implementation details. I will appreciate if somebody could check it’s validity. Given that expr is either an expression evaluating to (returning) an object, or a literal object, either mutable or immutable, and not just a name ; and f(y) = do\_with(y) then: x= expr makes the name/variable x bind to a new object (with new “reference” hence n…

> [@Why mutable structs are allocated on the heap?](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992):
>
> From [https://docs.julialang.org/en/latest/manual/types/#Mutable-Composite-Types-1:](https://docs.julialang.org/en/latest/manual/types/#Mutable-Composite-Types-1:) In order to support mutation, such objects are generally allocated on the heap, and have stable memory addresses. If I define: mutable struct MyT x::Int end and then use MyT inside a function, such as: function f(x::Int) q = MyT(x); q.x += 1 return q.x end I would expect q to be allocated on the stack, because it is a local variable that does not change type and MyT is isbits. But it is not: @btime f(1)…

but the bottom line is that deliberately leaving this unspecified and hidden from the user in normal circumstances is an important feature, and can be exploited by using immutables.

---

_[View the full topic](https://discourse.julialang.org/t/how-are-called-in-julia-terminology-int64-float64-vs-array-t-1-tuple-t1-t2-set-t/21006)._