Quoting Robert Engels (2019-04-06 08:00:02)
> But yes, similar to how all recursive functions can be rewritten using
> loops, which are more efficient, that is essentially what tail call
> optimization does - just that the process it automatic.
Not all recursive functions -- just tail calls. If you do stuff after
the call then you need to save state, which is what the call stack is
for.
You *could* use an explicit stack instead of using the call stack, but
whether this is more or less efficient is highly dependent on your
language implementation and the stack data structure you're using; I see
no reason to believe it would necessarily be more efficient in general.
---
Adding tail calls also has a few gotchas depending on how it interacts
with other parts of the language. For example, in the case of:
```
func foo () {
...
defer x.Close()
...
return bar()
}
```
The call to `bar()` is *NOT* a tail call, because `x.Close()` must be
called before the function actually returns. So this means they interact
in non-obvious ways with other parts of the language. One of the things
I like about Go is that most of the features interact in ways that are
easy to predict.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
