# Explicit denotation of variability and immutability

**URL:** <https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686>\
**Category:** Internals & Design\
**Tags:** proposal\
**Created:** [January 30, 2018, 10:16am UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686 "2018-01-30T10:16:36Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![SepandMeenu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sepandmeenu/32/8846_2.png) [@SepandMeenu](https://discourse.julialang.org/u/SepandMeenu)\
**Post date:** [January 31, 2018, 10:26am UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/23 "2018-01-31T10:26:11Z")

</div>

Thanks for the detailed reply, @StefanKarpinski.  
My proposal has admittedly shortcomings of different sort, but I felt a need for such a discussion when Julia is still in its infancy. So, I hope more critique/support/improvements will appear.

I understand your explanation of dynamic and static types in C++, but here I am mostly interested in the clarity of syntax – not optimisations which would aid the compiler (as @foobar_lv2 might prefer).  
Computational code is written and read by **humans** (not just machines), so clarity, explicity, and being less error-prone should be a goal for the design.

Let’s make an example; consider the following C/C++ snippet:

```julia
int foo(const int n, const* const int x, double y)
{
    //... do stuff ...
    return 0;
}

```

In this function definition, using `const` modifiers is _not_ just a means for producing optimised machine code; it is an _explicit_ “promise” from the programmer (a human!); in words, it says:

> The programmer promises that she will _not_ reassign `n` or `x`, and will respect the immutability of `x` in this part of the code.

Such a syntax will doubtlessly facilitate reasoning about the code for a second programmer who wants to read the code for understanding or debugging it.  
Another example from FORTRAN, explicit declaration of _pure_ functions:

```julia
pure function square(x)
  real, intent(in) :: x
  real :: square
  square = x * x
end function

```

In this snippet, it is easy for a compiler to determine the purity of a function, but it adds explicit “promises” from the programmer, which can be verified thoroughly by a compiler.

Such explicitness, imo, reduces a lot of human mistakes in code, while promoting better coding styles (esp., being easy to read and reason about) – hence, I disagree with StefanKarpinski’s statement that “local immutability doesn’t really buy you much”.

I do not see why we shouldn’t have such explicitness in Julia which is meant mainly for modern computational tasks. Julia has already made a decision to make user-defined types `immutable` by default, and to introduce an explicit keyword (`mutable`) when mutability is required. As StefanKarpinski mentioned, Julia has also `Immutable Arrays` – honestly, I do not understand the conceptual difference between a `Tuple` and an `Immutable Array`, and how `Immutable Array` fits into the type hierarchy (regarding StefanKarpinski’s statement, “a value can be mutated or not is a property of its type and that type cannot change…”).

I think, one can systematically generalize the aforementioned schemes to _all_ types, for instance, by a “mutation” of my proposal:

- Aggregate types – meaning the types which you can add or remove elements – like `Arrays`, `Vector`s, `Matrices`, `Dict`s, `Set`s, Graphs, Lists, etc., are _mutable_ by default, but one can “wrap [them] in an immutable wrapper” (as StefanKarpinski mentioned) to use them as immutables in some restricted scope (eg., in the body of a function); e.g.,

```julia
x = Array{Int64}(10) # constant binding to a mutable Array
xm = Immutable(x) # constant binding to an immutable view of x

```

- Non-aggregate types or user-defined types will be immutable by default (as the current standard for `struct`).

I still believe that one should keep a clear distinction between _equality_ and _assignment_ to markup modifications to the state:  
As in part (1) of my proposal, use `var` and `<-` (or `:=`) when dealing with (re-)assignments or modifying mutables, and reserve the equality operator (`=`) for a _constant_ binding.

The function signature should be also explicit in this regard, as I proposed in my original post.

---

_[View the full topic](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686)._