Is it web-compatible to revisit proper tail calls?

[littledan]

@msaboff started a discussion at tc39/ecma262#535 of whether it would be too late and/or bad for compatibility to revisit implicit proper tail calls. As that pertains to the proposal in this repository, rather than anything in the main ecma262 repository, let's have the discussion here. See that thread for discussion so far, but to summarize the arguments:

Too late to revisit implicit proper tail calls

• ES2015 is a ratified standard which calls for proper tail calls everywhere.
• We shouldn't relitigate what has already gotten consensus in good faith from the committee, including consensus from companies which are now opposing it.
• Websites may be developed against standards-conforming browsers, which would break without proper tail calls.
• Safari intends to ship proper tail calls in their next major release, which could make this a big compatibility issue once websites depend on it.
• Some idioms (@getify's) may be optimized to go faster with proper tail calls, although they have a fallback which works in all current browsers more slowly.

Not too late to revisit implicit proper tail calls

• No stable browser has shipped with proper tail calls; only Safari Tech Preview 1 and certain Chrome Canary builds (but not the current one). A page requiring PTC would already be broken.
• The ES2015 consensus on implicit proper tail calls didn't get as much implementation/devtools feedback as we would expect in the current process; now we are getting that feedback.
• We have revisited a number of ES2015 features already, for both web compatibility and implementation concerns; proper tail calls wouldn't be the first, and the others could also theoretically have compatibility issues.
• At this point, some browsers (e.g. Chrome Canary) have all major ES2015 features (modulo those changes described above) except proper tail calls, so it does not seem like there will be an unbounded amount of revisiting work in the future. The new process's requirement of implementation feedback should prevent as much revisiting in the future.

[littledan]

in tc39/ecma262#535 (comment) , @msaboff mentioned that, if PTC were optional (and not prohibited), then some browsers may ship it, causing some users to depend on it, and therefore causing compatibility issues.

My response would be that ES5 also had this problem; it also permits implicit proper tail calls. However, they were not shipped in any mainstream implementation, and no compatibility issue arose. There are all sorts of optimization-based potential incompatibilities which could arise (e.g., a website becomes too janky or uses too much memory to be usable in one browser, but not another), and it's not clear to me why this one should be a concern of TC39 and not others (beyond the programming model benefits that some sort of guaranteed proper tail calls brings).

[bterlson]

Using our typical heuristic of web compatibility (which is based on code currently being run by browsers today) a change here is certainly web compatible as web code does not depend on PTC to function. That may change in the future if implementations choose to ship PTC, however, but from what I've seen we do not make such assumptions when considering alternatives before us now.

[littledan]

@msaboff @wycats @bterlson @allenwb @concavelenz @getify @geoffreygaren @dherman @erights

[ljharb]

While I think "We think it should be a goal of the standard's evolution to avoid knowingly breaking existing standards-based code." in tc39/ecma262#535 (comment) would be nice to have - the ES spec has often knowingly broke existing standards-based code, as long as it didn't break actual code on the web.

In other words, for better or worse, the metric has consistently been that breaking "web code" matters, not breaking "existing standards-based code".

• where "web code" means "code that works on a majority of shipping browsers"

[msaboff]

I would prefer that we keep the discussion on one thread. Splitting this into multiple threads makes it difficult to track the arguments being made especially with cross thread links.

[nmn]

The only benefit I see from PTC is better transpiration by using trampolines. The current spec already includes implicit tail calls. And I prefer that solution in almost all ways.