Why tuples are immutable?

mkitti · December 3, 2023, 10:18am

We need to understand what a Tuple is first.

help?> Tuple
search: Tuple tuple NTuple ntuple NamedTuple @NamedTuple

  Tuple{Types...}

  Tuples are an abstraction of the arguments of a function – without
  the function itself. The salient aspects of a function's arguments
  are their order and their types. Therefore a tuple type is similar
  to a parameterized immutable type where each parameter is the type
  of one field. Tuple types may have any number of parameters.

Since they represent the arguments of a function, we might think they are about to enter the function’s stack. The stack is an abstract model for a processor’s register memory. Basically, the compiler needs to know a fixed size for all the arguments to create this stack of memory.

Moreover, immutability has a number of beneficial consequences. Immutable objects do not have to be copied when passed around. Also their known size and memory layout means they packed together efficiently or inlined into a larger structure.

Because of those benefits, immutable structs are the default in Julia. You can kne of the justifications why in the pull request below.

github.com/JuliaLang/julia

use `abstract|primitive type`, `struct`, `mutable struct` for type definitions

JuliaLang:master ← JuliaLang:jb/structkeywords

opened 10:22PM - 02 Feb 17 UTC

JeffBezanson

+1340 -1286

Fixes #19157. This regularizes the type-defining keywords and makes them more… accurately descriptive. The proposed syntax is ``` abstract type Integer <: Real end primitive type Int32 <: Signed 32 end struct Complex ... end mutable struct Ref ... end ``` This is nicely extensible for the future, avoids stealing the words abstract, primitive, and (im)mutable as keywords, and as a bonus supports Compat. 1. We should use the word `struct`; previously there was no keyword that described what the most common kind of user-defined type actually was. 2. We should steer people to immutable types by default. Immutable is generally better and faster, has better default behavior with `===`, and it's really pretty rare to need to update object fields. Base has many more immutable types than mutable, and in making this change it seemed to me that even more types could be made immutable. But `type Foo` looks more natural than `immutable Foo`, so `type` tends to be the default choice. This change reverses that, with `struct Foo` being more natural, and immutable. Writing `mutable struct Foo` makes you ask "does this really need to be mutable?", which is a good thing! 3. Immutable struct types are the closest thing we have to value type structs in other languages. We inline them in arrays in at least some cases, and being immutable makes it much harder to tell whether they are value or reference types. 4. FWIW, Rust also uses `struct` and makes them immutable. Not that we need to copy Rust, but it adds confidence that this is a reasonable thing to do. 5. We could eventually phase out mutable structs, and instead use `Ref` fields where needed in immutable structs. So far I really like the way this change looks. `immutable` is kind of a long and ugly word. The deprecation warning gives line numbers. I haven't updated the manual yet. I think we'll want to reorganize it a bit to introduce immutable structs first.