# Immutable reference
**URL:** https://discourse.julialang.org/t/immutable-reference/63405
**Category:** General Usage
**Created:** [June 22, 2021, 11:39pm UTC](https://discourse.julialang.org/t/immutable-reference/63405 "2021-06-22T23:39:36Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@jzr](https://discourse.julialang.org/u/jzr)
#### Post date: [June 22, 2021, 11:39pm UTC](https://discourse.julialang.org/t/immutable-reference/63405/1 "2021-06-22T23:39:36Z")
I want to pass a mutable object or array into a function and be sure that the object won’t be changed by that function. Is there an immutable wrapper I can use like `f(immutableview(x))`?
I know there are conventions like `f!(x)` but I would like a bit more assurance.
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [June 23, 2021, 1:25am UTC](https://discourse.julialang.org/t/immutable-reference/63405/2 "2021-06-23T01:25:18Z")
I do believe that, in general, no. Because every function that works over the type would need to have a method for the wrapper too, and at the same type this wrapper would need to be able to distinguish between things that change the object or not.
The only way I see is that: all your functions do not specify the type of the object they work with. Then you use a wrapper type that defines a `Base.getproperty` that delegates the query to the wrapped object. However, this will not prevent you changing an object that is stored in a field of the object (for example, if you have a vector field).
---
### Author:  [@ettersi](https://discourse.julialang.org/u/ettersi)
#### Post date: [June 23, 2021, 1:31am UTC](https://discourse.julialang.org/t/immutable-reference/63405/3 "2021-06-23T01:31:20Z")
I don’t think there’s a way to _guarantee_ that a mutable object is not modified. Julia does not have a notion of private fields, so it is always possible to manipulate the fields directly. A partial solution would be to introduce a wrapper type which errors if any of the usual modifiers like `setindex!` or `setproperty!` are called, but as @Henrique_Becker pointed out this wrapper would likely have to be specific to the type of object that you are working with (e.g. `AbstractArray`). So all in all, I’d say it’s not worth the fuss.
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [June 23, 2021, 2:09am UTC](https://discourse.julialang.org/t/immutable-reference/63405/4 "2021-06-23T02:09:59Z")
To complement, what you want is something that Ruby has done well. Every object automatically has a `freeze!` method, and if you call it, any change to a field of the object incurs in error.
---
### Author:  [@jzr](https://discourse.julialang.org/u/jzr)
#### Post date: [June 27, 2021, 8:56am UTC](https://discourse.julialang.org/t/immutable-reference/63405/5 "2021-06-27T08:56:23Z")
> **[GitHub - tkf/Mutabilities.jl](https://github.com/tkf/Mutabilities.jl)**
>
> Contribute to tkf/Mutabilities.jl development by creating an account on GitHub.
>
>
> This is part of a larger set of overhauls I'd like to do in the 2.0 timeframe (a…long with #21912 and other things along these lines). As such this is more of a straw-man implementation to play with various ideas. I doubt any of this code will get merged as is, but should provide a place for experimentation and we may start picking off good ideas from here.
>
> The basic concept here is that I think we're missing a heap-allocated \*immutable\* array. We have Array (mutable and dynamically sized), StaticArray (immutable and statically sized) and MArray (mutable and statically sized), but we don't really have an immutable dynamically sized array. This PR adds that.
>
> In my ideal world, most functions would return immutable arrays. In a lot of code, it is fairly rare to require semantically mutable arrays at the highest level of the API (of course operations are internally often implemented as mutating operations) and even in a good chunk of the cases that make use of them, they are used as a performance optimization rather than a semantic necessity.
>
> On the other hand, having an immutability guarantee can be quite useful. For example, it would solve a lot of the performance problems around aliasing (the reason LLVM can't vectorize in a lot of cases is that it doesn't know that the output array doesn't overlap the input array - if the input array is immutable that obviously can't happen).
>
> Immutability is also nice for higher level applications. Since views and slices are the same thing in immutable arrays, operations that would semantically be required to make copies on mutable arrays (say an AD system taking captures during the forward pass), can use views instead.
>
> Now, the problem here of course is that sometimes you do want mutation, particularly during construction of various objects (i.e. you construct the object once by setting something to every memory location, but then it's immutable afterwards). This PR introduces the \`freeze\` function, which takes a mutable array and returns an immutable array with the same memory contents. Semantically this function is a copy, but the idea is that the compiler will be able to elide this copy in most circumstances, thus allowing immutable arrays to be constructed using mutating operations without overhead. Similarly, there is the \`melt\` function which does the opposite. Once this infrastructure is mature, it should be trivial to get either the immutable or the mutable version in a zero-overhead (after compiler optimizations) manner of any array function just by adding the appropriate freeze/melt function. The 2.0 goal would then be to actually make most array operations return the immutable versions of the array.
>
> Another motivation here is to make it easier to write code that it generic over mutability in order to support things like XLA and other optimizing linear algebra compilers that operate on immutable tensors as their primitives. By having a well defined way to talk about mutability in the standard library, it should be easier to plug in those external implementations seamlessly.