{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/ecma262/issues/535","repository_url":"https://api.github.com/repos/tc39/ecma262","labels_url":"https://api.github.com/repos/tc39/ecma262/issues/535/labels{/name}","comments_url":"https://api.github.com/repos/tc39/ecma262/issues/535/comments","events_url":"https://api.github.com/repos/tc39/ecma262/issues/535/events","html_url":"https://github.com/tc39/ecma262/issues/535","id":147599667,"number":535,"title":"Response to the proposal to add explicit tail call syntax to ECMAScript","user":{"login":"msaboff","id":16887220,"avatar_url":"https://avatars.githubusercontent.com/u/16887220?v=3","gravatar_id":"","url":"https://api.github.com/users/msaboff","html_url":"https://github.com/msaboff","followers_url":"https://api.github.com/users/msaboff/followers","following_url":"https://api.github.com/users/msaboff/following{/other_user}","gists_url":"https://api.github.com/users/msaboff/gists{/gist_id}","starred_url":"https://api.github.com/users/msaboff/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/msaboff/subscriptions","organizations_url":"https://api.github.com/users/msaboff/orgs","repos_url":"https://api.github.com/users/msaboff/repos","events_url":"https://api.github.com/users/msaboff/events{/privacy}","received_events_url":"https://api.github.com/users/msaboff/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":26,"created_at":"2016-04-12T00:48:44Z","updated_at":"2016-04-13T01:24:20Z","closed_at":null,"body":"After some discussion with other JavaScriptCore team members, we at Apple cannot support the suggested change to make tail calls explicit via syntax due to the expected web incompatibilities those changes will create.\r\n\r\nGiven that tail calls are currently part of the ES6 and draft ES7 specification, a compliant implementation should implement tail calls as described in those specifications.  Compliance with any proposed changes would not occur for almost two years since the earliest that any proposed tail call changes could be adopted would be for the ES2017 (ES8?) specification.  In the mean time web pages and Javascript applications will be created that are susceptible to future breakage.  \r\n\r\nIn addition to the current JavaScriptCore implementation, it is likely that other browser venders will implement Tail Calls compliant with the current standard.  Let’s consider the changes to tail calls as suggested at the March 2016 TC-39 meeting and the impact it would have on Safari and any other compliant implementations that will be shipped this year.  I’d like to cover what I understood was being presented at the March meeting, but I will also cover two other reasonable variants of that proposal and my assessment of their suitability.\r\n\r\n1. **Tail calls based on tail position are optional. Tail calls based on opt-in syntax are required.**\r\nThere will be web pages and web applications developed starting this year that take advantage of tail calls as currently specified.  Those web pages would become susceptible to breakage should we change the specification.  Consider web pages that take advantage of tail calls as intended in the current specification.  The Javascript written for such a web page assumes unlimited tail calls.  Obviously, those pages won't work on an implementation that doesn’t support tail calls.  If one browser decides to stop supporting implicit tail call behavior, they break that class of web pages.  Therefore early adopters like us need to continue to support the currently specified behavior.  The implication of this is that ES6 tail call behavior cannot be made optional without compatibility issues for Safari.  Other early adopting browsers have the same issue.\r\n\r\n    If another browser decided to not support implicit tail calls, but waits for the proposed change and only implements explicit tail calls, they introduce cross browser incompatibilities.  Certainly such a browser is not compatible when running a web page that depends on implicit tail calls and likely never will be.  In addition, there would be at least another class of incompatibilities.  Consider a web page that inadvertently makes infinite recursive calls.  For browsers that waited for explicit tail calls, that web page could throw an out of memory exception that might be silently caught, after which the web page proceeds as expected.  For Safari and other browsers that support implicit tail calls, that web page is stuck in an infinite loop.  The error is in the web page, but the handling of the error by each browsers is vastly different depending on their support of implicit tail calls.  We have seen this type of issue in the past and reduced our stack size to maintain cross browser compatibility.\r\n\r\n    Approval of this proposal also encourages browser vendors to wait to implement the current ES6 specified tail call behavior.  This selective delay by some implementations diminishes the purpose of the ECMAScript standard and the features contained therein.  Selective support by various implementations will cause developers to delay their adoption of the programming patterns tail calls was designed to address.  Again this only impacts early adopting browsers like Safari.\r\n\r\n    The main problem with this proposal is that it relaxes normative behavior and makes it optional, effectively eliminating that behavior from the standard.  After we work through the early adopter problems described above, we’d introduce a new problem: Developers don’t know if they can use tail calls based on tail position or not, since implementations vary.  Feature testing for the optional tail call behavior would be difficult and cumbersome, given the current specification.  Optional behavior without a feature test has little place in the standard and cannot be relied upon by implementors and developers alike.\r\n\r\n    Given these web compatibility issues and related developer concerns, we reject this type of proposal.\r\n\r\n2. **Tail calls based on tail position are forbidden. Tail calls based on opt-in syntax are required.**\r\nA proposal based on this option requires that early adopting implementations, like Safari, need to change and stop supporting implicit tail calls.  Those changes break web pages designed for the current spec as described above.  It not only breaks those web pages, it would require that they be rewritten.  The web breakage and subsequent rework by web developers caused by this option is much worse than with the first option.\r\n\r\n    There will also be web pages that accidentally took advantage of and benefited from implicit tail calls.  With this proposal, those web pages could break due to running out of stack space.  These breakages would be confusing at best to the web page implementers and likely damage the perceived quality of Safari.\r\n\r\n    Due to the breakage this imposes on Safari and web pages developed to use implicit tail calls, we also reject this type of proposal.\r\n\r\n3. **Tail calls based on tail position are required. New syntax for verifying tail position is required.**\r\nThis is the only proposal that wouldn’t cause breakage.  This proposal would be to add syntax to signify a tail call is intended, but wouldn’t change the normative nature of tail calls as currently specified.  If the call is not in tail position, a syntax error is issued.  Implicit tail calls as currently defined would still be normative and must be implemented by conforming implementations.  This change is backward compatible.  Pages developed to take advantage of proper tail calls without the new syntax would continue to work.  Javascript code developed with the new syntax get additional checking and the added benefit that tail calls appear different in the source code.  The usefulness of this change is minimal though as it adds optional syntax with little corresponding semantic changes.\r\n\r\n    We recommend against this proposal, but our objection is not as strong as our objections to (1) and (2), since this proposal would not harm web compatibility.  Our main concern is that this proposal could add confusion with very little benefit."},"comment":{"url":"https://api.github.com/repos/tc39/ecma262/issues/comments/209178960","html_url":"https://github.com/tc39/ecma262/issues/535#issuecomment-209178960","issue_url":"https://api.github.com/repos/tc39/ecma262/issues/535","id":209178960,"user":{"login":"msaboff","id":16887220,"avatar_url":"https://avatars.githubusercontent.com/u/16887220?v=3","gravatar_id":"","url":"https://api.github.com/users/msaboff","html_url":"https://github.com/msaboff","followers_url":"https://api.github.com/users/msaboff/followers","following_url":"https://api.github.com/users/msaboff/following{/other_user}","gists_url":"https://api.github.com/users/msaboff/gists{/gist_id}","starred_url":"https://api.github.com/users/msaboff/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/msaboff/subscriptions","organizations_url":"https://api.github.com/users/msaboff/orgs","repos_url":"https://api.github.com/users/msaboff/repos","events_url":"https://api.github.com/users/msaboff/events{/privacy}","received_events_url":"https://api.github.com/users/msaboff/received_events","type":"User","site_admin":false},"created_at":"2016-04-13T01:24:20Z","updated_at":"2016-04-13T01:24:20Z","body":"> >  During various TC-39 discussion, it has been made clear the there should never be the need for feature testing Spec'ed ES normative behavior\r\n\r\n> I don't believe this is true - in fact, it seems like the opposite to me. Can you elaborate or link to notes?\r\n\r\nI don't know if it is in the notes, but I suggested at one point feature testing some other feature and the response was that the committee wasn't going to go back to that kind of world.  Besides, normative behavior doesn't need a feature test.\r\n\r\n> I still am missing something critical here, though, so please forgive me. I don't understand how feature detection with PTC is easier than with STC. Scenario: I'm a dev who wants to use either my PTC/STC-dependent algorithm or a less efficient one (possibly transpiled). Basically only option with PTC is recurse a bunch of times and look for an error, unreliable as you say. If we have STC, the situation is at most just as bad, but can be made easier by taking advantage of the fact that no one will actually ship a browser with STC syntax but without STC semantics. Testing for syntax seems like a very easy litmus test that will be valuable in practice. Thoughts?\r\n\r\nFeature testing for PTC or STC would be about the same if a developer wanted to make sure that each really made the tail calls they expected.  Having to feature test for both and deciding what to do based on the combinations complicates things.  Consider Safari version N supports PTC but not STC.  Later, version N+1 supports both PTC and STC.  It is likely that other browsers will support only STC.  At some point, good web apps will need to check for PTC and STC, and select among three broad code paths.  This seems unruly for developers.  That's one way that STC makes tail call feature testing more complicated.  Given this complexity, a developer decides to only checks STC syntax and drops their PTC check and corresponding path.  The result is that we'll lose out for users with Safari N due to the complexity of checking and coding for both PTC and STC."}}