# Prevent function from changing arguments (like constant pointer in C)?

**URL:** <https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980>\
**Category:** New to Julia\
**Created:** [July 20, 2017, 5:55pm UTC](https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980 "2017-07-20T17:55:14Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![tuckermcclure](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tuckermcclure/32/1187_2.png) [@tuckermcclure](https://discourse.julialang.org/u/tuckermcclure)\
**Post date:** [July 20, 2017, 5:55pm UTC](https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980/1 "2017-07-20T17:55:14Z")

</div>

In C, one can declare that an input for a function is a constant pointer. The function can read from it, but not write to it. Is there an equivalent in Julia?

Context: I’m writing a function, `foo`, that takes in a user’s function, `bar`. `foo` calls `bar` with some arguments, and I want to make sure `bar` isn’t modifying the arguments that `foo` is giving it. Those arguments can consist of mutable composite types of arrays and such things that might be easily overwritten.

I could create a deep copy before passing it in, but this seems like extra work – these arguments might become very large.

Here’s the pattern:

```julia
function foo(bar)
    ins = go_get_a_bunch_of_structured_data()
    outs = bar(ins) # Could use deepcopy, but that takes a long time.
    something_else(ins) # Hopefully not changed by 'bar'!
end

```

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [July 20, 2017, 6:15pm UTC](https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980/2 "2017-07-20T18:15:20Z")

</div>

> [@tuckermcclure](#):
>
> In C, one can declare that an input for a function is a constant pointer. The function can read from it, but not write to it

As a matter of fact, you can’t do that in C. Casting away the `const` is **NOT** a UB in C (it is a UB if you want to modify an object with const storage I believe). So keeping that in mind

> [@tuckermcclure](#):
>
> Is there an equivalent in Julia?

Yes, don’t put `!` in the function name and document the expected behavior.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [July 20, 2017, 6:17pm UTC](https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980/3 "2017-07-20T18:17:23Z")

</div>

> [@tuckermcclure](#):
>
> In C, one can declare that an input for a function is a constant pointer. The function can read from it, but not write to it. Is there an equivalent in Julia?

The only thing I can think of is to take something like an array and wrap it in a read-only view type (i.e. an `AbstractArray` type much like `SubArray` but which doesn’t define `setindex!`).

---

<div class="post-metadata">

**Author:** ![bramtayl](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bramtayl/32/3614_2.png) [@bramtayl](https://discourse.julialang.org/u/bramtayl)\
**Post date:** [July 20, 2017, 7:14pm UTC](https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980/4 "2017-07-20T19:14:58Z")

</div>

You could test the user function on small set of arguments and error if they get modified

---

<div class="post-metadata">

**Author:** ![tuckermcclure](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tuckermcclure/32/1187_2.png) [@tuckermcclure](https://discourse.julialang.org/u/tuckermcclure)\
**Post date:** [July 20, 2017, 7:55pm UTC](https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980/5 "2017-07-20T19:55:49Z")

</div>

> [@yuyichao](#):
>
> As a matter of fact, you can’t do that in C.

I’m probably misunderstanding what you’re saying, but what I mean to say is that the following compiles fine in C++:

```c
int foo(double * x)
{
  x[1] = 3.14;
  return int(x[1]);
}

```

whereas this (note the `const`) does not compile (g++ 4.7):

```c
int foo(const double * x)
{
  x[1] = 3.14;
  return int(x[1]);
}

```

The error it throws is `error: assignment of read-only location`.

I was hoping to take advantage of a similar pattern in Julia.

The reason I’m so concerned with this is that I’m writing part of a package, and the particular thing I’m doing here is something users (who haven’t read every last little note in the documentation) mess up with alarming regularity. I’m trying to design a good interface so my users will know that they’ve created a problem without undue run-time overhead.

> [@bramtayl](#):
>
> You could test the user function

Thanks, @bramtayl. This would probably be good most of the time, but if there’s in `if` in there, I’ll never know if some branches change the inputs and some don’t. You’re right that it’s better than nothing!

> [@stevengj](#):
>
> The only thing I can think of is to take something like an array and wrap it in a read-only view type (i.e. an AbstractArray type much like SubArray but which doesn’t define setindex!).

That’s an interesting idea.

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [July 20, 2017, 8:06pm UTC](https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980/6 "2017-07-20T20:06:24Z")

</div>

> [@tuckermcclure](#):
>
> whereas this (note the const) does not compile (g++ 4.7):  
> int foo(const double \* x)  
> {  
> x[1] = 3.14;  
> return int(x[1]);  
> }

The const here is only a hint and has no effect on the program’s behavior (ok it affects overload but that’s it)

The user function can simply do `double *_x = (double*)x;` or `double *_x = const_cast<double*>(x);` and the code is perfectly well defined C/C++ code.

---

<div class="post-metadata">

**Author:** ![tuckermcclure](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tuckermcclure/32/1187_2.png) [@tuckermcclure](https://discourse.julialang.org/u/tuckermcclure)\
**Post date:** [July 20, 2017, 9:04pm UTC](https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980/7 "2017-07-20T21:04:57Z")

</div>

Thanks, @yuyichao. I see your point. I think a hint is totally acceptable for me (especially one that throws a compiler error!). I’m just trying to prevent honest accidents. So I take this to mean that no such hint is possible in Julia?

---

<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:** [July 21, 2017, 2:07pm UTC](https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980/8 "2017-07-21T14:07:56Z")

</div>

Certain protections are possible, eg the one mentioned by @stevengj above, but at the same time they can be circumvented by a determined user (eg if wrapping in a `struct` that does not define `setindex!`, simply access the relevant field directly). You might as well just follow good practices (functions that modify end in `!`).

For small vectors, also see

> **[GitHub - JuliaArrays/StaticArrays.jl: Statically sized arrays for Julia](https://github.com/JuliaArrays/StaticArrays.jl)**
>
> Statically sized arrays for Julia. Contribute to JuliaArrays/StaticArrays.jl development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![tuckermcclure](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tuckermcclure/32/1187_2.png) [@tuckermcclure](https://discourse.julialang.org/u/tuckermcclure)\
**Post date:** [July 21, 2017, 6:31pm UTC](https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980/9 "2017-07-21T18:31:19Z")

</div>

Ok, thanks all. I’ll probably use a `deepcopy` to prevent the user from being able to mess up the data.

Does anyone out there think it would be useful to have some kind of hint to Julia that a given argument should not be modified? I don’t care if it’s bullet-proof – just something to prevent slip-ups. Does this even make sense for the way Julia deals with the code?

---

<div class="post-metadata">

**Author:** ![barche](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/barche/32/79_2.png) [@barche](https://discourse.julialang.org/u/barche)\
**Post date:** [July 21, 2017, 7:34pm UTC](https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980/10 "2017-07-21T19:34:02Z")

</div>

The main problem I have with this is that the promise of non-mutability propagates to all functions you call, so for example if you call `length` on an array, that function must be annotated as non-mutating. Having spent countless hours of chasing const-correctness in C++, I can’t help but wonder about the following:

1. How many programming errors were actually prevented?
2. Would it not have been simpler to just fix any errors like this, rather than chasing the holy grail of const correctness only to end up being forced to do a `const_cast` because of some external library?

---

<div class="post-metadata">

**Author:** ![Per](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/per/32/10387_2.png) [@Per](https://discourse.julialang.org/u/Per)\
**Post date:** [July 22, 2017, 5:50am UTC](https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980/11 "2017-07-22T05:50:23Z")

</div>

Let’s say Julia had a special type corresponding to constant pointers. Let’s call it `Immutable`. Calling `length(Immutable(A))` where a is an `Array` would then require that `length` has a method for `Immutable{Array}`.

Unlike C, the library that provides the `length` function would not be machine code. Even if the programmer who wrote the `length` function didn’t foresee an input of this type, the JIT compiler will attempt to create a method for it. Given proper sub-typing rules, it should succeed, but the new method will throw an error whenever `setfield!` tries to change a field in the input, and `getfield` will convert mutable fields into `Immutable`. So the task of “chasing const correctness” would basically be handled by the compiler and the dispatch system. (It would even be possible to call functions that sometimes mutate their input, and the call would succeed if they did not mutate in this particular case.)

It should still be possible to get a `Ptr` from an `Immutable` using `Base.unsafe_convert`, so that `ccall` will work as expected. Thus `unsafe_convert` could also be allowed to convert `Immutable{T}` into `T` directly. This would make it clear that `Immutable` objects are only for detecting programmer errors. It would be much, much harder to implement this as a security feature.

(Overwriting `setfield!` and `getfield` for a user type is not allowed, for obvious reasons. So this would have to be implemented at a lower level.)

---

<div class="post-metadata">

**Author:** ![barche](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/barche/32/79_2.png) [@barche](https://discourse.julialang.org/u/barche)\
**Post date:** [July 22, 2017, 8:13pm UTC](https://discourse.julialang.org/t/prevent-function-from-changing-arguments-like-constant-pointer-in-c/4980/12 "2017-07-22T20:13:19Z")

</div>

This looks like an elegant solution to me, especially since this is completely opt-in. It reminds me of a feature I have wished for:

```julia
struct Foo{T} <: T end
# or
mutable struct Foo{T} <: T end

```

The idea is that this would create a wrapper type that behaves exactly like `T`, except that it is possible to define methods that specifically take a `Foo{T}`. It would not be allowed to add any fields, only the fields already in `T` would be present. This combined with getfield/setfield overriding would allow implementing your `Immutable` as a special case. Another application could be logging of calls to specific functions. My use case for it would be to make C++ smart pointers behave the same way as the pointed-to type.

Since this effectively introduces inheritance from a concrete type in this specific case, I’m pretty sure there are some major objections to implementing this.