ES6 tail calls controversy

[kangax]

Certain anonymous sources tell me that basically all web browsers except Safari hate es6 tail calls because they slow the rest of JS down and that folks on TC39 also absolutely hate tail calls as well.

Apparently, Chrome engineers also feel that one of the things keeping the pressure on implementing tail calls is our compatibility table.

In light of all of this, I'm asked to consider to modify the tail call entry in a table to have an asterisk saying that there isn’t a lot of support for the feature or that it's controversial or something along those lines.

I'm bringing it up here to see what ya'll think and if we can come to some kind of consensus.

/cc @ljharb @sebmarkbage

[ljharb]

Let me correct your anonymous sources a bit:

• PTC (proper tail calls) is not the same as TCO (tail call optimization) - and in fact is NOT an optimization. PTC is in the spec, TCO is not. PTC is solely to prevent blowing the stack. So, anyone that has the expectation that it will make their code faster is very mistaken - this will rarely be the case.
• Two browsers have no complaint about implementing tail calls. Two of them do, which is why the STC (syntactic tail calls) proposal was created, and why TC39 debated tail calls extensively at the last meeting.
• There are certainly conflicting beliefs - among implementors, users, and among the committee - about the value of implicit tail calls vs explicit tail calls, about the importance of stack frames vs eliding them, about the performance implications, etc. However, "controversial" isn't really relevant - classes are controversial, slow things down in implementations, etc, and they don't get nor need an asterisk, because they're in the spec.
• Perhaps this table is creating some of the PTC pressure - but much of the pressure is coming from programmers who feel that they need this feature.

At the moment, the feature is in the spec. Everyone quite simply will be building it, although there's the possibility that one or two implementors won't be able to performantly or quickly build to 100% compliance. There are indeed open questions about whether PTC will remain required by the spec, whether STC will be added, or both or neither. Until those questions are resolved, or until an implementor publicly declares that they're refusing to implement PTC, "the spec" is the arbiter of truth, and I believe there should be no differentiation on this feature from any other in the spec.

[sebmarkbage]

^ GitHub won't let me heart @ljharb's comment so I'll just ❤️ it here.

[rvagg]

Cross-linking Node discussion about this nodejs/CTC#3

[ljharb]

I've been corrected on a few parts of my post, so I wanted to qualify some points

• apparently 3 of the 4 major browsers have slightly differing and partially overlapping concerns about PTC. I won't go into the details because they're long and complex, but the recent meeting notes are public for anyone to study.
• I didn't mean to imply that classes were anywhere near as controversial - in the same way, or with the same players, or with the same level of pushback from implementors - as PTC. PTC is clearly the most controversial part of ES6/ES2015; I'm just making the argument that "controversial" isn't relevant to the compat table.
• I said "everyone quite simply will be building it" and followed up with a qualifier. To be more accurate, I think it is likely that more than one of the browsers will ship it, and that will provide enough pressure on the remaining browsers to ship it despite their individual implementation cost. Perhaps I'm wrong on that - but until that's proven in either direction, ¯_(ツ)_/¯

To sum up, I'm saying that the compat table's goal should be to represent both the spec, and defacto web standards, but not to represent current controversy or debate. The table gets updated after every TC39 meeting with the results, and I think that should continue to be the case - there's no point in marking "people are arguing about this".

[littledan]

For V8's part, although we've implemented tail calls, we're not shipping them at the moment. We've heard significant concerns from users about disruptions to development/debugging flows, but we have not heard strong demand from users for the feature. We are currently trying to gather more information about the size of the impact on users which we can use to determine whether we will ship PTC. I don't think any other major browser has a PTC implementation ready to ship at this moment, so I think @ljharb's prediction is a bit premature.

At the last TC39, my impression was that there was very broad support for simply removing the PTC feature, though it did not achieve consensus at that meeting. PTC is one of the few parts of the spec represented in the Kangax table that seems like it could possibly change. ("no assignments allowed in for-in head" is another, see tc39/ecma262#260.) I don't know whether this compat table should represent things under discussion with an asterisk; a compat suite that I spend more time with, test262, does not bring active discussions into scope until they are at least at Stage 3 at TC39. I don't have an opinion about whether it should be in scope for Kangax to represent.

[sebmarkbage]

@littledan I think the reason you're not seeing any demand from users is self-fulling. If they feel passionate about PTC they already use a different language to compile to JS (or a native platform). That's the people we want to join us. The only people currently affected are people that already use JS so you'll only hear from that group's minor inconvenience.

[YurySolovyov]

I wonder why is issue wasn't raised while choosing features for the spec.

[ljharb]

@YurySolovyov the process for changes to the language for > ES6 is quite different than <= ES6.

[YurySolovyov]

I also get a bit frustrated that discussion is on how to remove it from spec (or refuse to implement it in some other way), rather than how to actually implement it.
Did any vendor done any research concerning efficient or at least good enough implementation?
I think it would be useful to shift discourse from "We can't do it good enough, let's not do it at all" to "We can't do it ATM because of ... but let's find out how it can be possible"

[chicoxyzzy]

@YurySolovyov

• PTC is implemented in WebKit Nightly
• V8 has implemented PTC, but has been holding back on shipping
• Both Microsoft and Mozilla (IonMonkey bug, OdinMonkey bug) has faced problems implementing PTC
• There is STC proposal
• ...and Apple's response to STC

[YurySolovyov]

That's roughly 1.99/4, if you count WebKit Nightlies as shipped.
Is there any data from Apple about impact for real-world sites?

[craigbilner]

@kangax - are the direct and mutual recursion tooltips the official benchmark for whether a platform supports PTC? I've been looking forward to this for some time now to improve my FP code but AFAICT Safari 10 is still falling over on these, some manual tests I've done and this old post. Am I missing something?

[chicoxyzzy]

I think we shouldn't change anything in the table. PTC is in the spec and it's a significant feature of ES6.

[zloirock]

By my opinion, we should remove it only if and when it will be removed from the next versions of ES.

[chicoxyzzy]

@zloirock original @kangax's proposal was

to modify the tail call entry in a table to have an asterisk saying that there isn’t a lot of support for the feature or that it's controversial or something along those lines.

[zloirock]

@chicoxyzzy I see. I mean we should remove it from the table if it will be removed from the spec, otherwise - leave it as is without any comments. It's not decided and now it can confuse someone.

[chicoxyzzy]

So I think we can close this because most of us agreed on keeping things unchanged.

All other discussions such as removing PTC from spec, STC and difficulties of implementation are out of scope of this repo.

[kylebakerio]

link for apple's response was broken, here's the correct link:
tc39/ecma262#535

[chicoxyzzy]

@finetype thank you. Updated my comment

[hax]

In past half year it seems still no consensus of PTC vs STC, and only webkit/safari implement PTC.

I suggest to reopen this issue. And I think we can just add a flag comment refer to this issue.

[chicoxyzzy]

@hax tail calls are in spec and our test looks fine. I think there is no reason to mention STC anywhere in the table.

[chicoxyzzy]

Thinking again, we can add a note with a link. Should we? @ljharb @zloirock

[ljharb]

It would be fine to add a note, but I'm not sure I see the value in it.

[littledan]

If users rely on this table to guide web development, understanding that it references what they will eventually be able to use and what browsers are converging on, a note could help clarify that we see no particular movement towards other browsers supporting PTC. OTOH maybe that's already apparent from the table's contents.

[enright]

The arguments against implementing proper tails calls are astoundingly weak. I have to rely on Node 6 to run the asynchronous arrow code I write. This is plainly pathetic. The compat-table is doing the right thing: showing vendors who refuse to follow spec.

[gynet]

It's very disappointing that a group of ppl brought up a spec (ES6) everyone was happy with but some of them are "having no plan" to implement it (silently).

[ljharb]

@gynet that should tell you that everyone wasn’t happy with it. The pre-es6 process left a lot to be desired, I’m afraid.

[YurySolovyov]

It seems like it is implementable, but it may have a slightly worse DX in case of tail call, but I think someone form Apple did some statistics and not that many read-world calls are in tail position so DX damage is probably overrated.

[ljharb]

If that’s the case (that it’s rare), then implicit tail calls might not have been sufficiently motivated.

[gynet]

On the contrary, logically, it could be possible because es6 PTC does not get implemented by v8, ppl are not able to add code have too much TCs.

[YurySolovyov]

If that’s the case (that it’s rare), then implicit tail calls might not have been sufficiently motivated.

1. That's an argument switching. This is about if they are implementable, not whether they are sufficiently motivated. If engine claims it conforms to standard but has no PTC, then it is a lie.
2. That's a chicken-egg problem. If people can't rely on PTC, they won't write code that uses them.