# Type inference with a functional programing style

**URL:** <https://discourse.julialang.org/t/type-inference-with-a-functional-programing-style/70105>\
**Category:** Performance\
**Created:** [October 20, 2021, 5:11pm UTC](https://discourse.julialang.org/t/type-inference-with-a-functional-programing-style/70105 "2021-10-20T17:11:20Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![Lilith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lilith/32/27492_2.png) [@Lilith](https://discourse.julialang.org/u/Lilith)\
**Post date:** [October 20, 2021, 5:46pm UTC](https://discourse.julialang.org/t/type-inference-with-a-functional-programing-style/70105/3 "2021-10-20T17:46:01Z")

</div>

> [@lmiq](#):
>
> You can solve the problem by simply changing the label used in the inner function

I’m aware of that, but unfortunately, my `silly_last` relies on the side effects.

> [@lmiq](#):
>
> I would say that having closures modifying captured values makes the code hard to follow, besides these problems.

In those examples, yes they do. And yet they also have a place. In a `map(x) do ... end` block the closure is clearly only used in `map` and easy for me to reason about: the stuff in the closure happens once for every item in the collection and then the closure is gone forever. It would be nice if the compiler could reason about this the same way supported functional programming as well as the syntax does (see also [tail-call optimization](https://discourse.julialang.org/t/recursive-call-vs-while-loop/7723)).

---

_[View the full topic](https://discourse.julialang.org/t/type-inference-with-a-functional-programing-style/70105)._