"When debugger is active tail calls are disabled."
This sounds like going down a path where running code can change its semantics depending on the debugger being open or not. Would some web pages fail if I have it open? Would the original case from issue 457 still fail because the console is part of the debugger?
And BTW, the more common term for this is "Tail Call Elimination", when it is a language feature rather than a random optimization.

Does this activity from July mean that TCO is going to be shelved for the foreseeable future and/or forever (just a question, not a complaint), or is it just lower on the list relative to other P2 issues? (Or has no decision either way been taken yet, which would be understandable?)
Thanks. -- T.J.

@adamk: Thanks. I wouldn't have expected the Chrome Platform Status page to be where this would be indicated. When I read that (and I had), I figured it mean Chrome was doing nothing until V8 did something.
But again: No active development _now_ or for the foreseeable future? The [proposal for a syntactic flag on tail calls][1] mentioned in that blog post is currently on the list of ["inactive" proposals][2].
Just trying to get a clear picture, if there is one, whether TCO is "dead" in V8 barring movement on that proposal, just delayed with no active development at present, or if that decision hasn't been taken.
Thanks -- T.J.
[1]: https://github.com/tc39/proposal-ptc-syntax
[2]: https://github.com/tc39/proposals/blob/master/inactive-proposals.md

For future reference, V8 indeed uses chromestatus.com to track its work on ECMAScript features.
It's hard to predict the future, but we currently have no plans to do work on tail calls in V8, for the reasons stated in the blog post (and the subsequent inactivity of the syntactic proposal).

I specifically write functional JavaScript code that relies on proper tails calls. I am stuck using Node 6 to do it. Not implementing this feature is about politics, not technical difficulty. Actually, it's been implemented. This isn't a defect really. It's just a refusal to follow the spec.

It's actually extremely frustrating that this still isn't past the feature-flag stage and in live chrome. The specification for javascript approved this change when will the chrome team put their personal beliefs aside and implement javascript as the spec outlines.

Unfortunately there was a strong belief that the stack trace would be
unreliable. This is however a misnomer as it is only recursive (and co
recursive) functions that would lack stack trace, which is very desirable,
because a stack trace of thousands of same function calls are useless
anyway.
If you could please convince front end engineers in their wrong
assumption... I for one would do a happy dance. But so far only ignorence
have prevailed.

I would love to embrace a more functional style of programming, but missing out on this specced (es2015) feature is blocking me.
AFAIK there were some concerns around speed. Those should have evaporated by now. Once this is implemented, not having to manage a stack should be faster, right?
There was also an issue that you could not render stack-traces inside recursive functions. As Jon mentioned, that is actually a plus, not a downside. As long as the functions name is mentioned in the stack it's ok. perhaps just put the first iteration on the stack? and when it calls out to another recursive function do the same? Adding a marker so one can see it's call tail optimized function?
Let 2019 be the year where V8 becomes 100% spec compliant :)

Re #83: This is not true. Any tail call site in any strict mode function will be affected, i.e. in case of
```js
"use strict";
function foo() { return bar(); }
function bar() { throw new Error; }
foo();
```
the stack trace would indicate that bar is called from top level.

What do you mean? The stack trace is just that, a trace of the current execution stack. So whatever get's removed from the stack (via tail calls) has no chance of showing up on a trace of said stack later.
Ideas like shadow stacks have been discussed a lot in this context, but this would have to be on in production all the time, and so it'll eat additional resources even if you never throw an exception, since production time is the most important time here, as you'll need to make sense of the Error.stack's in your logfile to do any kind of post-mortem debugging (both client and server side).

hmm, ok so a call tail optimized function needs still to be on the stack
then. Can the optimization kick in on the second iteration?
What I mean is everything processes as usual. Then I hit a CTO function.
when this happens I look if the current function is already on the stack,
if not add it, otherwise just progress without pushing additional traces.
I'm pretty sure that is a very oversimplified way of putting it, Still, it
seems the logical thing to do to me.
Also, only CTO functions will pay this cost, and not the rest of the
runtime. Also, the cost will be lessened by the fact that we don't need to
manage the start after the first iteration.
I know this is not 100% CTO, but it gets really close and will lift the
current limitation on recursive programming
Op wo 6 feb. 2019 om 08:27 schreef bmeu… via monorail <
monorail+v2.824767423@chromium.org>:

There are various different hacks how to go about this, all of them come with their own obstacles and drawbacks. A lot of thought went into this already on our side.
The real problem though is the spec and the fact that it hijacked tail call sites in strict mode functions and gave those new semantics in ES6. This essentially makes proper tail calls an "opt out" feature (aka a "footgun") in ES6. With a tiny spec change this could be turned into an "opt in" feature (i.e. with special syntax for tail calls), and then it would probably be straight-forward to ship this.

Make a shadow stack; put it behind a flag so people can turn it on when they think they need it; see how usage of that flag dwindles away into nothingness as the fog of FUD disappears; remove the shadow stack.
That, or let ignorance prevail, as said above.

Re: 89, I know. I have discussed this issue before IRL with some of you. I
just hoped some of the issues had been elevated by now.
Special syntax for this feature would be a boon, as that would make much
more clear to the programmer what's going on.
However, I'm not seeing any activity on this either in TC39. IIRC there is
a proposal for this that's stalled on stage 0/1?
(I hope I missed something and there is a boatload of activity!)
Is there something I can do to get that moving again?
I love JS. A more functional way of programming is within reach, but the
current state of affairs is blocking truly embracing this.
Op wo 6 feb. 2019 om 09:13 schreef e… via monorail <
monorail+v2.3921524156@chromium.org>:

TBH I haven't looked closely into why the syntax proposals have been blocked by the committee, so I cannot really comment on that. It seems like someone really has to pick it up from here and get everyone in a room to come to an agreement, and then we can implement that proposal.

As for "personal beliefs", it's not personal beliefs that are keeping V8 from implementing tail calls, but rather something of a stale-mate at TC39 (V8 is not the only engine represented there that objects to implicit tail call syntax, and would prefer explicit syntax).
That said, V8's issue tracker isn't the right place for that spec discussion. If you'd like to engage with the spec, https://github.com/tc39/ecma262/issues/535 is probably the best place to do so, currently.

As long as there are no real facts, this *is* a "personal belief" thing.
Example from https://bugs.chromium.org/p/chromium/issues/detail?id=568695#c17,
abbreviated:
pfeldman: TCO pretty much kills debugging (and profiling) and brings no
value to the average user.
me: Do you *truly* believe that [this is] some conspiracy to "kill
debugging and profiling"...?
pfeldman: I have no better explanation :)
This is just a belief, and its from someone @chromium.org. If there is
anything close to *facts*, it would be safari adding tail calls, and the
world not breaking as a result. (I couldn't even find one place where
someone complains about it.)
========
You're pointing to the explicit syntax proposal, which is a bad idea.
I've described it in the last bullet of my reply at
https://github.com/tc39/proposal-ptc-syntax/issues/23#issuecomment-386972698
-- but a more explicit explanation: tail call elimination at the level
of my own code is one side of the problem which I can resolve all by my
lonesome (eg, by using loops). The other side is when such tail calls
go through some higher-order third-party library code. When *that*
happens, and I implement something that should be a functional loop but
I depend on that library (eg, a loop that goes through some promise
mechanics), then I could ask the author to please add "continue"
everywhere. Given the current FUD, a likely answer is "no", and then I
get stuck, or I fork that library in the best tradition of piling
messes.
And as if to ensure that the above scenario does happen, that proposal
chooses a looooong keyword. (Also useful to deter random bypassers from
accidentally using this mysterious academic trick that we don't know
much about.) My personal belief (yes, really) is that this *will* be
real disaster, since it will result in a world where people would
conveniently say "you see, we made it possible for you freaks to get
tail calls, and nobody used them, now go away".
========
Finally, I find it dubious that the common line here is "it's not just
us". Any random search for "chrome market share" will tell you why.

#93 If that should be solved at TC39 level, why isn't google actively participating in that issue? Send some of your devrels or TC39 members there to resolve current blockers and work on the proposal. As #94 pointed out, given chrome market share, you guys can make a real impact there.

Google is actively participating (I am the primary V8/Google representative), both on the tail call issue in particular and in TC39 in general. We also have devrel folks involved. It just so happens that this is not an easy matter to resolve.