In full generality, I don’t think you can do this in julia.
In your example, both versions of rettest do the same thing, as evidenced by
function caller3()
v=ones(Float64,100)
s=ones(Float64)
for k=1:10 #in reality 1000000000 instead of 10
rettest(v,s)
end
@show v[1]
nothing
end
caller3()
#v[1] = 1024.0
The extra allocations are very small: They allocate space for the tuple of pointers (to v and s).
It is an eternal gripe of mine that and multiple return-values containing gc-controlled pointers (aka mutable objects) are currently heap-allocating in julia. See e.g.
https://discourse.julialang.org/t/immutables-with-reference-fields-why-boxed/7706/21. The general strategy is that you should try to avoid (in inner loops) to create tuples or nontrivial immutables containing references to mutable objects; only exception is that wrappers around mutable objects are OK (wrapper means: The mutable object is the only field).
Otoh, the heap-allocation for these small objects is really fast, and sometimes the compiler can optimize it out entirely.
In your specific example, you could use broadcasting.
For single-element arrays, you could also use Ref.
If you need to return multiple values, at least one of which is mutable, then the non-allocating way is to pass Ref{}s for the scalars and write to them. This looks really ugly, so the general consensus is that you take the performance hit for the allocation of the tuple, or play with @inline until the compiler decides that the alloc can be skipped; unless this really is an inner loop.