# 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:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [January 31, 2018, 2:44pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/41 "2018-01-31T14:44:12Z")

</div>

Thanks for the explanation, I see what you mean now, and you have a point.

My point was that the following should be equivalent (identical machine code), except for call-site syntax in C++:

```julia
mutable struct M
    v::Cint
end

function f(x::M)
    x.v=2
    return
end

void f(int &x) {
    x = 2;
    return;
}

void fptr(int* x) {
    *x = 2;
    return;
}

```

And julia does not support C+±like syntax, which is a decision that makes me happy; it is as explicit as C.

---

<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:** [February 1, 2018, 11:15am UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/42 "2018-02-01T11:15:05Z")

</div>

I came across the implementation of immutability in the D language; it is very similar to my proposal:

> <https://stackoverflow.com/questions/17115900/what-is-the-difference-between-const-and-immutable-in-d/17119659#17119659>

see also:

> **[Type Qualifiers - D Programming Language](https://dlang.org/spec/const3.html)**
>
> Comparison of const between the D programming language, C++, and C++0x

esp. the section “Immutable Type”.

---

<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 1, 2018, 11:51am UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/43 "2018-02-01T11:51:24Z")

</div>

> [@SepandMeenu](#):
>
> it is very similar to my proposal

I don’t know D, but I find it very hard to map the concept of a reference (as implied by that answer) to Julia.

---

<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:** [February 1, 2018, 12:09pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/44 "2018-02-01T12:09:12Z")

</div>

Some related stuff on Julia Github ([https://github.com/JuliaLang/julia](https://github.com/JuliaLang/julia))

- Immutable Dicts  
[https://github.com/JuliaLang/julia/blob/2d90358b14830beb6aef975eea0009bf01973b44/base/dict.jl](https://github.com/JuliaLang/julia/blob/2d90358b14830beb6aef975eea0009bf01973b44/base/dict.jl)

- Immutable Arrays  
[https://github.com/JuliaGeometry/ImmutableArrays.jl](https://github.com/JuliaGeometry/ImmutableArrays.jl)

- Fixed-Size Arrays  
[https://github.com/JuliaLang/julia/issues/5857](https://github.com/JuliaLang/julia/issues/5857)

- Immutable Types  
[https://github.com/JuliaLang/julia/blob/d8233f94bea6b67eb7f684097a774c018775f181/doc/src/manual/types.md](https://github.com/JuliaLang/julia/blob/d8233f94bea6b67eb7f684097a774c018775f181/doc/src/manual/types.md)  
\*\* Advatages for immutable structs:  
– It can be more efficient. Some structs can be packed efficiently into arrays, and in some cases the compiler is able to avoid allocating immutable objects entirely.  
– It is not possible to violate the invariants provided by the type’s constructors.  
– Code using immutable objects can be easier to reason about.  
\*\* An immutable object might contain mutable objects, such as arrays, as fields. Those contained objects will remain mutable; only the fields of the immutable object itself cannot be changed to point to different objects.  
\*\* Two essential properties define immutability in Julia:  
– An object with an immutable type is passed around (both in assignment statements and in function calls) by copying, whereas a mutable type is passed around by reference.  
– It is not permitted to modify the fields of a composite immutable type.

---

<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:** [February 1, 2018, 12:14pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/45 "2018-02-01T12:14:10Z")

</div>

I am just providing examples for treating mutability/immutability in other languages. That might help to get an idea, but they may not be necessarily applicable in Julia.  
We have to give the idea a lot of thinking before it crystalises. In this regard, experience from the design of other languages, like Haskell, Rust, or D, might be helpful.

It also shows clearly that this is a very important issue in modern languages.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [February 1, 2018, 12:39pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/46 "2018-02-01T12:39:18Z")

</div>

You seem to be under a misapprehension about the development stage of Julia. It is not “in its infancy” and it has already quite thoroughly crystallized. We are not spitballing about the basics of how the language works at this point. We are currently in the process of working out the very last API changes for the 1.0 release.

As I explained in my earlier post, your proposal is not merely some additional language or compiler feature, it is fundamentally incompatible with how types work in Julia. The design of not having separate static and dynamic types was decided upon eight years ago and has not changed since then. It is deep in the identity of the language.

While you’re welcome to continue to speculate about type systems with these kinds of features, please be aware that you are speculating about hypothetical languages that have minimal relevance to Julia.

---

<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:** [February 1, 2018, 12:57pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/47 "2018-02-01T12:57:09Z")

</div>

Thanks for the notice – though it sounds rather harsh. I supposed that being in version \< 1.0 means being “in infancy” – sorry for the misinterpretation.

My hope is that such a radical proposal or speculation would help shape the future of the language in some way – I remain optimistic.  
The items from the Julia Github indicate, imo, that the concept of immutable types is still under consideration/debate anyway, and novel ideas might arrive to change the language.

BTW, could you please explain the place of `Immutable Array`s or `Immutable Dict`s in the type hierarchy? You mentioned earlier that “whether a value can be mutated or not is a property of its type and that type cannot change”; so I cannot see, for instance, the relative position of `Immutable Array`s compared to `Arrays` in the type hierarchy.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [February 1, 2018, 1:08pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/48 "2018-02-01T13:08:25Z")

</div>

Immutable types are well and good. It’s the notion of casting between mutable and immutable types or changing the behavior of a value with type annotations which are non-starters. Immutable and mutable arrays are just different kinds of arrays, both subtypes of `AbstractArray`. There is no issue with having some arrays that are mutable and some which are immutable. What you cannot do is have a mutable array and turn it into an immutable array or vice versa. If an object has one type, that is always its type, and the mutability is part of the type.

---

<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:** [February 1, 2018, 1:30pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/49 "2018-02-01T13:30:25Z")

</div>

This

> [@StefanKarpinski](#):
>
> What you cannot do is have a mutable array and turn it into an immutable array or vice versa

seemingly contradicts what you said before,

> [@StefanKarpinski](#):
>
> Interestingly, making a mutable wrapper around an immutable object is actually useful and efficient, even though at first blush it seems to violate immutability.

Could you elaborate on that?  
Is there a general mechanism in Julia (like a macro) with which one can “derive” an _immutable_ object from a _mutable_ one?

---

<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:** [February 1, 2018, 1:32pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/50 "2018-02-01T13:32:02Z")

</div>

What do you think about the first part of my proposal, distinguishing between assignment and equality in the syntax?

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [February 1, 2018, 5:40pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/51 "2018-02-01T17:40:21Z")

</div>

> [@SepandMeenu](#):
>
> > What you cannot do is have a mutable array and turn it into an immutable array or vice versa
> 
> seemingly contradicts what you said before,

How so? Mutability is a property of the type of something and you cannot change the type of something. Therefore you cannot change whether something is mutable or not.

> > Interestingly, making a mutable wrapper around an immutable object is actually useful and efficient, even though at first blush it seems to violate immutability.
> 
> Could you elaborate on that?

I wrote a paragraph about it and linked to a rather long issue discussing the technique in detail. What specifically would you like more detail about?

> Is there a general mechanism in Julia (like a macro) with which one can “derive” an immutable object from a mutable one?

No, not automatically, at least not at this point. I would potentially be possible through metaprogramming and generating types.

> What do you think about the first part of my proposal, distinguishing between assignment and equality in the syntax?

Julia already distinguishes assignment syntactically from both mutation and equality. There are the following assignment-like syntaxes:

- `x = ...` is assignment. The name `x` is bound to the value that the `...` evaluates to. Local bindings never leak out of their scope. It doesn’t matter what `x` was bound to before this happens, that _value_ is not affected in any way. No object is mutated by this and no other binding besides `x` is changed.

- `x.f = ...` is equivalent to `setproperty!(x, :f, ...)` which, by default mutates the object `x` by changing its field `f` to the value of the expression `...`. If `x` is visible in another scope or by another bindings, this change will be seen everywhere. No bindings are changed by this.

- `x[i] = ...` is equivalent to `setindex!(x, ..., i)` which, for arrays mutates the array `x` by changing its `i`th slot to refer to the value of the expression `...`. If `x` is visible in another scope or by another bindings, this change will be seen everywhere. No bindings are changed by this.

There are equality operators `==` and `===` which check for value-based equality and identity-based equality, respectively. There is also already a syntax for creating a constant binding as opposed to a variable binding:

```julia
const x = ...

```

The `const` annotation is not currently supported in local scopes. But as I said, that’s a fairly straightforward feature which has not been added because it has limited benefits – both humans and compilers can easily tell if a local binding could potentially be reassigned in the same scope or not. That is, of course, not the case for global bindings which is where the `const` declaration is really useful.

We could have bindings constant by default, but decided (consciously) not to. In local scope, defaulting to constant bindings is just annoying and has little benefit – if you want a constant local binding, just don’t re-assign something; as a human or a compiler, it’s easy to see if a local is assigned multiple times. In global scope it would be quite beneficial for bindings to be constant by default. However, this would be _very_ annoying for interactive usage in the REPL where it’s really common to reuse and overwrite variable names. Since code that depends on non-constant global bindings is also usually quite slow in Julia (precisely because it’s hard to analyze statically), there’s a rather strong incentive not to use non-constant global bindings in code where performance matters at all. Some have suggested that this performance hazzard is actually a feature since it discourages the use of mutable global state.

---

<div class="post-metadata">

**Author:** ![Liso](https://avatars.discourse-cdn.com/v4/letter/l/898d66/32.png) [@Liso](https://discourse.julialang.org/u/Liso)\
**Post date:** [February 1, 2018, 9:58pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/53 "2018-02-01T21:58:45Z")

</div>

there is also:

```julia
x(i) = f(i) # f could be undefined here

```

what happend here?

---

<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:** [February 2, 2018, 9:26am UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/54 "2018-02-02T09:26:40Z")

</div>

Let me first emphasise that I mean _no_ radical change to the fundamental structure, type system, or the logic of Julia – it is already a lovely “progressive” language. My proposal is meant towards a more readable and safer **syntax** for translating computational algorithms into Julia. How it would be implemented under the hood is a matter for core developers and the more knowledgeable part of the community – I am no computer scientist, but coming from the math realm.

1. Most succinctly, what I propose is certain _explicit_ **syntactical** safeguards to denote **mutation of values and bindings** (mutations of the state). I firmly believe that it leads to much better coding style in the long run, especially benefits concurrent/parallel programming.

For example, according to the proposal, by

```julia
a = 2
b = Array{Int32}(10)
c = ImmutableArray{Int32)(5, 5)

```

the programmer and the code reader (plus the compiler) will be sure that `a` is an _immutable_ binding to the value 2, `b` is an _immutable_ binding to a mutable `Array`, and `c` is an _immutable_ binding to an _immutable_ `Array`. If, somewhere else in the code, such decisions/pledges are violated, the compiler will throw an error or a warning.

Mutability will be then explicitly marked up, as in

```julia
v::Integer := 2
w := -1.5
z.c0 := f
z[i] := 32a + h(2)

```

where everybody (along with the compiler) is informed that `v` is intended to be a _mutable_ binding (but with _immutable_ type) to a value 2, `w` is a _mutable_ binding (with _mutable_ type) to a value, -1.5, and `z.c0` and `z[i]` values are _intentionally_ mutated.

Using `:=` for mutation and `=` for constant binding (in the corresponding global or local scopes) does not hurt any fundamental principle of Julia, or a quick-scripting user of the interactive mode. In fact, it promotes better coding style which is also closer to the mathematical syntax and much safer (since the compiler knows the intent of the programmer and can warn her if needed).

1. For further safety inside function bodies and easier reasoning about the code, I see a strong need for an _explicit_ syntactical mechanism like the `intent` keyword of FORTRAN (see above); for instance, by a construction like

```julia
# a pure function
function fp(a::Int64, s::Set{Int32})  
    #... do some computation ...
end

```

the programmer explicitly promises not to mutate the bindings of the arguments or their contents in the function body, so that

```julia
a = 2
a := -1
push!(s, 9)
s = Set([1, 2])
s := s2

```

will produce compiler errors.  
In contrast, a definition like

```julia
# an impure function
function fip(var a::Int64, mut s::Set{Int32})
    #... do some computation ...
end

```

allows

```julia
a := 2 
a += 1
push!(s, 9)
a = 2 # `a` becomes constantly bound thereafter

```

where `var` and `mut` are “flags” to show explicitly that the programmer intends to mutate the binding/value of `a` and mutate the contents of `s` with this function.  
This is also not against any fundamental principles of Julia, afaiu, but leads instead to much safer codes, which are very easy to reason about by a _human_.  
[Note: I am not insisting on this particular notation; better notation could be devised for this purpose.]

1. I think there is a need for an in-built mechanism to map mutable types to immutable types _automatically_; e.g., suppose that somebody has built up a library which includes a mutable type `List` with a `push` method to append elements to the `List`. Then something like

```julia
typealias ImmutableList Immutable(List)

```

will generate an immutable-`List` type which can only be initialized; moreover, any mutation method built for `List` will produce an error when applied to `ImmutableList`; e.g., after the generation of the immutable type above, and defining

```julia
lm = List([1, 2, 3])
lim_1 = ImmutableList([5, 6, 7])
lim_2 = ImmutableList(lm) # an immutable copy of `lm`

```

either of

```julia
push!(lim_1, 8)
push!(lim_2, 4)

```

will produce a compile error, while

```julia
push!(lm, 4) # does not mutate `lim_2`

```

works fine.

This is the only radical part of my proposal, if at all. I am not sure how this could be implemented in Julia or if this violates Julia’s foundations. Yet, that seems to be quite a useful mapping.

_Implicit_ mutation is the “dangling pointer” of modern languages. 😇

---

<div class="post-metadata">

**Author:** ![ScottPJones](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scottpjones/32/146_2.png) [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)\
**Post date:** [February 2, 2018, 1:07pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/55 "2018-02-02T13:07:36Z")

</div>

If it is just a syntactical layer over Julia, have you thought about implementing this either via metaprogramming, or taking something like [https://github.com/JuliaLang/JuliaParser.jl](https://github.com/JuliaLang/JuliaParser.jl), and adapting it to the syntax that you want?  
The fact that Julia lowers the Julia syntax to `Expr`s and then does the rest of its magic on the `Expr`s means that it is incredibly flexible in that regard. (again, kudos to the four creators of Julia!)  
Somebody has even done a radically different syntax based on Clojure over Julia.

I think that would be a much more productive path towards reaching your goals.  
If you do it well, maybe you’ll then be able to attract a larger community around your more explicit variant of Julia.

---

<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:** [February 2, 2018, 3:02pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/56 "2018-02-02T15:02:01Z")

</div>

That’s a good recommendation. However, I do not have the know-how or experience to build such a parser. Could you refer me to some references which might help?  
Currently, I am still waiting for critiques, suggestions and improvements to my proposal.

---

<div class="post-metadata">

**Author:** ![improbable22](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/improbable22/32/5464_2.png) [@improbable22](https://discourse.julialang.org/u/improbable22)\
**Post date:** [February 2, 2018, 6:03pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/57 "2018-02-02T18:03:23Z")

</div>

It sounds like much of what @SepandMeenu wants could be obtained if `a @=...` expanded to `const a = ...` . Infix operators don’t seem to produce infix macros, though:

```julia
←(a,b) = a+b
1 ← 2

macro (←)(a, b) println("got ",a," and ",b) end
@← 1 2

```

But it should be simple to make a macro which acts on all `←` and `=` in your code. With [MacroTools.jl](https://github.com/MikeInnes/MacroTools.jl)?

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [February 2, 2018, 7:09pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/58 "2018-02-02T19:09:50Z")

</div>

> [@SepandMeenu](#):
>
> Using `:=` for mutation and `=` for constant binding (in the corresponding global or local scopes) does not hurt any fundamental principle of Julia, or a quick-scripting user of the interactive mode.

As I’ve said, there’s already a syntax for this: `x =` means what you propose `x :=` should mean and `const x =` means what you propose `x =` should mean. Playing musical chairs with this syntax seems like fairly pointless endeavor that doesn’t actually fix anything and will make the language considerably less familiar to programmers coming from most mainstream languages. It is also _way_ too late in the game to do this since it would break every Julia program everywhere. The only feature missing for bindings is that `const x =` is not currently supported for local `x`, but as I’ve explained several times, it’s not particularly important and will be added in the 1.x series.

> [@SepandMeenu](#):
>
> the programmer explicitly promises not to mutate the bindings of the arguments or their contents in the function body

This whole proposal seems predicated on the idea that function arguments work like they do in Fortran or like pass-by-reference arguments do in C++ where assigning to `a` in your example changes the caller’s `a`. That is not the case – that never happens in Julia. A function cannot affect the local bindings of its caller. If a function assigns some other value to an argument `a` it only affects what `a` refers to inside that function. We don’t need to annotate this because it’s not a problem in the first place.

Regarding the mutation of `s`, that’s a different story. A function _can_ mutate an object passed to it, which will be visible to the caller. There is already a syntactic convention for this in Julia: functions that mutate one or more of their arguments have names ending in `!` as in `push!`. What you seem to want above and beyond this is an explicit annotation of which arguments are mutated. Currently, that’s a matter of documentation.

If you want to _enforce_ that a function only mutates arguments which are annotated for mutation, that’s vaguely plausible, but it’s actually quite difficult and maybe impossible in a language with as powerful dynamic dispatch and higher order programming as Julia. It would probably have to be a runtime check rather than a compile time check, although it might be possible to check some subset of cases statically. Adding this feature would complicate the implementation of the language _considerably_ and seems of dubious value considering that the `!` mutation convention has been quite effective without incurring any implementation complexity.

> [@SepandMeenu](#):
>
> I think there is a need for an in-built mechanism to map mutable types to immutable types automatically

I’m not really sure this makes much sense. The implementations of immutable and mutable data types that are conceptually similar are often quite different. This is certainly not something that is going to happen in Julia 1.0. Perhaps something like this could happen in Julia 2.0.

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [February 2, 2018, 7:17pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/59 "2018-02-02T19:17:31Z")

</div>

For what it’s worth, I think if you spend some more time programming in Julia (or a language where this sort of thing works similarly such as Python) you will gain some distance from C++ and may no longer see this sort of thing as useful. In C++ explicit statements of variability and immutability are deeply ingrained in the way we think about things, but frankly in Julia a lot of that stuff seems rather pointless.

---

<div class="post-metadata">

**Author:** ![simonbyrne](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simonbyrne/32/19_2.png) [@simonbyrne](https://discourse.julialang.org/u/simonbyrne)\
**Post date:** [February 2, 2018, 7:19pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/60 "2018-02-02T19:19:19Z")

</div>

> [@SepandMeenu](#):
>
> I think there is a need for an in-built mechanism to map mutable types to immutable types automatically;

[#11902](https://github.com/JuliaLang/julia/issues/11902) and [#21912](https://github.com/JuliaLang/julia/pull/21912) are in that spirit.

---

<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:** [February 3, 2018, 4:29pm UTC](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686/61 "2018-02-03T16:29:55Z")

</div>

I believe that a syntactical convention being “less familiar to programmers coming from most mainstream languages”, e.g., as you say here

> [@StefanKarpinski](#):
>
> Playing musical chairs with this syntax seems like fairly pointless endeavor that doesn’t actually fix anything and will make the language considerably less familiar to programmers coming from most mainstream languages.

should not pose a problem to Julia designers/learners. What you say in the next paragraph,

> [@StefanKarpinski](#):
>
> This whole proposal seems predicated on the idea that function arguments work like they do in Fortran or like pass-by-reference arguments do in C++ where assigning to a in your example changes the caller’s a. That is not the case – that never happens in Julia.

clearly shows that Julia is not afraid to have its own conventions – be they different from the mainstream or not. And I think programmers can learn – as we learned to say farewell to once-common `GOTO`.

It is neither “playing musical chairs”, nor “fairly pointless endeavor”, Stefan. It’s an endeavour for the clarity of syntax of computational code, and its better compliance with mathematical notation. The essence of my proposal is, as I have mentioned several times, a modification of the syntax to **make mutations explicit** in any scope. The stylistic convention to add `!` to the name of functions which mutate one of their arguments is clearly in this direction. I just say: **Let’s generalize this nice decision systematically**. I think, sadly, you are underestimating the value of such an explicitness. ☹

Note that I do _not_ insist on its _enforcement_ either; I would be happy even with _warnings_. In this way, you’ll not break any previous code, but promote a better style of code for the future where mutability in binding or value is explicitly denoted. If the programmer _intends_ to mutate something in any scope, she should make that explicit.

Unfortunately, I don’t have an idea how difficult it can be to implement. That’s far above my knowledge.

[Previous page](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686.md?page=2)

[Next page](https://discourse.julialang.org/t/explicit-denotation-of-variability-and-immutability/8686.md?page=4)