# In-place functions with arrays and scalars
**URL:** https://discourse.julialang.org/t/in-place-functions-with-arrays-and-scalars/28885
**Category:** General Usage
**Created:** [September 18, 2019, 11:40am UTC](https://discourse.julialang.org/t/in-place-functions-with-arrays-and-scalars/28885 "2019-09-18T11:40:02Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@HenrikM](https://discourse.julialang.org/u/HenrikM)
#### Post date: [September 18, 2019, 11:40am UTC](https://discourse.julialang.org/t/in-place-functions-with-arrays-and-scalars/28885/1 "2019-09-18T11:40:02Z")
For a function that returns scalars and arrays, what is good practice for the mutating version? Below, `x` and `y` are scalars and `A` and `B` are arrays.
```julia
function f(...)
x = ...
y = ...
A = ...
B = ...
return x, A, y B
end
```
This doesn’t work:
```julia
function f!(x, A, y, B, ...)
x = ...
y = ...
A = ...
B = ...
end
```
I could do like this, but it feels ugly:
```julia
function f!(A, B, ...)
x = ...
y = ...
A = ...
B = ...
return x, y
end
```
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [September 18, 2019, 11:43am UTC](https://discourse.julialang.org/t/in-place-functions-with-arrays-and-scalars/28885/2 "2019-09-18T11:43:46Z")
Last version makes sense to me.
---
### Author:  [@HenrikM](https://discourse.julialang.org/u/HenrikM)
#### Post date: [September 18, 2019, 11:54am UTC](https://discourse.julialang.org/t/in-place-functions-with-arrays-and-scalars/28885/3 "2019-09-18T11:54:37Z")
I think this leads to arranging function arguments according to their type instead of semantics. Otherwise you have to keep track of which of the arguments are mutating and which are not.
```julia
x, A, y, B = f(...)
# Mutating:
f!(x, A, y, B, ...)
# Non-mutating:
x, y = f!(A, B, ...)
```
Incremental computation is also affected:
```julia
x_t, A_t, y_t, B_t = f(....)
x += x_t
A += A_t
y += y_t
B += B_t
```
Instead of
```julia
f!(x, A, y, B, ...)
```
for a function
```julia
function f!(x, A, y, B, ...)
x += ...
y += ...
A += ...
B += ...
end
```
---
### Author:  [@HenrikM](https://discourse.julialang.org/u/HenrikM)
#### Post date: [September 18, 2019, 11:55am UTC](https://discourse.julialang.org/t/in-place-functions-with-arrays-and-scalars/28885/4 "2019-09-18T11:55:42Z")
Has everyone just settled for what @kristoffer.carlsson suggested or are there other solutions?
---
### Author:  [@tim.holy](https://discourse.julialang.org/u/tim.holy)
#### Post date: [September 18, 2019, 12:17pm UTC](https://discourse.julialang.org/t/in-place-functions-with-arrays-and-scalars/28885/5 "2019-09-18T12:17:22Z")
```julia
xref, yref = Ref(x), Ref(y)
f!(xref, X, yref, Y, ...)
```
There is no way to mutate a value. You can only mutate things stored inside the value. Consequently you can mutate `[5]` but not `5`. There’s nothing Julia-specific about that statement.
---
### Author:  [@yuyichao](https://discourse.julialang.org/u/yuyichao)
#### Post date: [September 18, 2019, 12:24pm UTC](https://discourse.julialang.org/t/in-place-functions-with-arrays-and-scalars/28885/6 "2019-09-18T12:24:43Z")
Also note that none of the version above mutates `A` and `B`.
---
### Author:  [@mschauer](https://discourse.julialang.org/u/mschauer)
#### Post date: [September 18, 2019, 12:27pm UTC](https://discourse.julialang.org/t/in-place-functions-with-arrays-and-scalars/28885/7 "2019-09-18T12:27:40Z")
I defend always the following: `!` is a licence to modify, not an obligation.
Then
```julia
ynew = f!(y)
```
can be used as idiom for generic code which does not stop working when replacing a `MVector` by an `SVector`. Unfortunately that is not strictly followed in Base.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [September 18, 2019, 12:27pm UTC](https://discourse.julialang.org/t/in-place-functions-with-arrays-and-scalars/28885/8 "2019-09-18T12:27:58Z")
Modifying multiple arguments is usually a strong signal that they should be organized into a composite type (`struct`) or at least a `NamedTuple`.