# Best way to have an optional return value?

**URL:** <https://discourse.julialang.org/t/best-way-to-have-an-optional-return-value/12184>\
**Category:** General Usage\
**Tags:** question\
**Created:** [July 5, 2018, 3:55pm UTC](https://discourse.julialang.org/t/best-way-to-have-an-optional-return-value/12184 "2018-07-05T15:55:21Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![kellertuer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kellertuer/32/220707_2.png) [@kellertuer](https://discourse.julialang.org/u/kellertuer)\
**Post date:** [July 5, 2018, 3:55pm UTC](https://discourse.julialang.org/t/best-way-to-have-an-optional-return-value/12184/1 "2018-07-05T15:55:21Z")

</div>

I am starting to enjoy many features of Julia. I just haven’t found the best way to provide an optional return value. Lets say we have a function (improvised not compiled)

```julia
function myAlg(x::Float,y::Float)
    if x > y
        z=y;
        reason="A";
    else
        z=x;
        reason="B";
   end
   return z,reason
end

```

where `reason` is an additional return value that might provide more information but is not a result per se.

What is the best way to make that `reason` optional?  
My first idea would be `function myAlg(x::Float,y::Float; returnReason=false)`

and a

```julia
if returnReason
    return z,reason
else
    return z
end

```

but is that type stable and intended that way?  
Is there a better and nicer way to only get the reason returned if I explicitly ask for it?  
What’s the best practice for such a szenario?

Kind Regards,  
Kellertuer

---

<div class="post-metadata">

**Author:** ![rdeits](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rdeits/32/286_2.png) [@rdeits](https://discourse.julialang.org/u/rdeits)\
**Post date:** [July 5, 2018, 4:13pm UTC](https://discourse.julialang.org/t/best-way-to-have-an-optional-return-value/12184/2 "2018-07-05T16:13:39Z")

</div>

You’re correct that your `returnReason` keyword argument will make the result type-unstable. One way you can get around this is by taking advantage of multiple dispatch by using a new type to indicate the kind of result you want. This is how, for example, Interpolations.jl works:

```julia
struct RequestReason # this immutable type has no fields, so constructing it is essentially free
end

function myAlg(x, y)
  return x + y
end

function myAlg(x, y, ::RequestReason)
  return x + y, "A"
end

```

So now you can call `z = myAlg(x, y)` or `z, reason = myAlg(x, y, RequestReason())` and the result will be type-stable (since the return type is fully defined by the argument types).

It’s also worth noting that the compiler is improving in its ability to handle limited type-unstable code. In particular, in Julia v0.7, there’s some degree of constant propagation, so you can do:

```julia
julia> function myAlg(x, y, returnReason=false)
         z = x + y
         if returnReason
           return z, "A"
         else
           return z
         end
       end
myAlg (generic function with 2 methods)

julia> function g()
         z, reason = myAlg(1.0, 2.0, true)
       end
g (generic function with 1 method)

julia> @code_warntype g()
Body::Tuple{Float64,String}
2 1 ─ %1 = π (3.0, Float64) │╻ myAlg
  │ %2 = Core.tuple(%1, "A")::Tuple{Float64,String} ││
  └── return %2  

```

Because the `requestReason` argument was set to the constant `true` inside the function `g()`, the compiler in v0.7 is able to propagate that constant through the body of `myAlg` and correctly infer that `myAlg` will return two arguments. However, I believe this constant propagation is not currently performed for keyword arguments (note that I made `returnReason` a positional argument in my definition above).

---

<div class="post-metadata">

**Author:** ![kellertuer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kellertuer/32/220707_2.png) [@kellertuer](https://discourse.julialang.org/u/kellertuer)\
**Post date:** [July 5, 2018, 5:41pm UTC](https://discourse.julialang.org/t/best-way-to-have-an-optional-return-value/12184/3 "2018-07-05T17:41:26Z")

</div>

Thanks for the clarification – I first thought of `kwargs` because my function has them anyways, but maybe a positional one would do, too. I’m still on 0.6 so I might try the `type`-based approach, though in total I feel a little too typed already 😉

---

<div class="post-metadata">

**Author:** ![rdeits](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rdeits/32/286_2.png) [@rdeits](https://discourse.julialang.org/u/rdeits)\
**Post date:** [July 5, 2018, 6:04pm UTC](https://discourse.julialang.org/t/best-way-to-have-an-optional-return-value/12184/4 "2018-07-05T18:04:29Z")

</div>

Yeah, makes sense. A couple of other options for v0.6 would be:

1. Always return both and let the caller decide whether to ignore the second result
2. Always return both `z` and a `Nullable{String}`, only giving the nullable a value if the user requests it
3. Just be type-unstable. Lots of good Julia code is type-unstable, and the performance impact can be pretty small. If this function gets called frequently in a loop, then type stability is important, but if it’s just called occasionally then it may not matter. Benchmarking with BenchmarkTools.jl will help show whether it’s worth even worrying about type stability here.

---

<div class="post-metadata">

**Author:** ![kellertuer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kellertuer/32/220707_2.png) [@kellertuer](https://discourse.julialang.org/u/kellertuer)\
**Post date:** [July 6, 2018, 8:04am UTC](https://discourse.julialang.org/t/best-way-to-have-an-optional-return-value/12184/5 "2018-07-06T08:04:16Z")

</div>

Maybe the third is a good idea, if – as you mentioned – it is improving in 0.7.  
It is not a function called within a loop, even more I could to that in my outer wrapper having `kwargs` in order to provide a nice user access, since the inner one (just positional optional values) should be efficient already.  
For the outer one I don’t care for efficiency that much. The main reason for the outer one is in fact to distinguish between an efficient inner implementation (with a not so nice interface, since on always has to remember all positions of optional arguments) and an outer function with a nice interface with optional kw-arguments, more validation, and better error messages and such.

---

<div class="post-metadata">

**Author:** ![rdeits](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rdeits/32/286_2.png) [@rdeits](https://discourse.julialang.org/u/rdeits)\
**Post date:** [July 6, 2018, 12:58pm UTC](https://discourse.julialang.org/t/best-way-to-have-an-optional-return-value/12184/6 "2018-07-06T12:58:21Z")

</div>

That’s reasonable too.

By the way, it’s also worth noting that, while they don’t get the constant propagation yet, keyword arguments in v0.7 are actually fast (they are passed as named tuples instead of dictionaries). So you might find that it’s no longer necessary to have a special inner function that takes only positional arguments.

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [July 6, 2018, 2:06pm UTC](https://discourse.julialang.org/t/best-way-to-have-an-optional-return-value/12184/7 "2018-07-06T14:06:33Z")

</div>

> [@rdeits](#):
>
> So you might find that it’s no longer necessary to have a special inner function that takes only positional arguments.

Any keyword function always called a special inner function that only had positional arguments.

---

<div class="post-metadata">

**Author:** ![rdeits](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rdeits/32/286_2.png) [@rdeits](https://discourse.julialang.org/u/rdeits)\
**Post date:** [July 6, 2018, 2:30pm UTC](https://discourse.julialang.org/t/best-way-to-have-an-optional-return-value/12184/8 "2018-07-06T14:30:56Z")

</div>

Er, right, but it might not be necessary to write that inner function manually and ask users to call it just for performance reasons.

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [July 6, 2018, 2:45pm UTC](https://discourse.julialang.org/t/best-way-to-have-an-optional-return-value/12184/9 "2018-07-06T14:45:19Z")

</div>

Yeah, sorry if I misunderstood you.

---

<div class="post-metadata">

**Author:** ![kellertuer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kellertuer/32/220707_2.png) [@kellertuer](https://discourse.julialang.org/u/kellertuer)\
**Post date:** [July 7, 2018, 6:23am UTC](https://discourse.julialang.org/t/best-way-to-have-an-optional-return-value/12184/10 "2018-07-07T06:23:56Z")

</div>

I also provide a different call mechanism (using two `struct`s) for the user that way (in the idea of an experienced user calling the function often with different parameters) – so it’s also that the function without keyword arguments has its own reasoning. Still it’s nice to hear that in general it’s not necessary required to do two such functions.