Type inference with a functional programing style

[Lilith]

@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).