{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/proposal-flatMap/issues/59","repository_url":"https://api.github.com/repos/tc39/proposal-flatMap","labels_url":"https://api.github.com/repos/tc39/proposal-flatMap/issues/59/labels{/name}","comments_url":"https://api.github.com/repos/tc39/proposal-flatMap/issues/59/comments","events_url":"https://api.github.com/repos/tc39/proposal-flatMap/issues/59/events","html_url":"https://github.com/tc39/proposal-flatMap/issues/59","id":303635236,"number":59,"title":"Use HTML feature opt-in for language level compatibility","user":{"login":"jonrimmer","id":183786,"avatar_url":"https://avatars1.githubusercontent.com/u/183786?v=4","gravatar_id":"","url":"https://api.github.com/users/jonrimmer","html_url":"https://github.com/jonrimmer","followers_url":"https://api.github.com/users/jonrimmer/followers","following_url":"https://api.github.com/users/jonrimmer/following{/other_user}","gists_url":"https://api.github.com/users/jonrimmer/gists{/gist_id}","starred_url":"https://api.github.com/users/jonrimmer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jonrimmer/subscriptions","organizations_url":"https://api.github.com/users/jonrimmer/orgs","repos_url":"https://api.github.com/users/jonrimmer/repos","events_url":"https://api.github.com/users/jonrimmer/events{/privacy}","received_events_url":"https://api.github.com/users/jonrimmer/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-03-08T21:18:41Z","updated_at":"2018-03-08T22:37:41Z","closed_at":"2018-03-08T21:37:52Z","author_association":"NONE","body":"Since the only problem with proposals like `\"flatten\"` (and others) is in the web runtime, why is this a problem that needs to be solved at the standard-library level? I agree that web-compatibility has to be considered, but wouldn't the more appropriate place to solve it be in the browser?\r\n\r\nThere is already work underway at the W3C [to support explicit feature opt-in (and opt-out)](https://wicg.github.io/feature-policy/). Couldn't there be a feature-policy for ES compatibility as well, either through the kind of HTTP-header mechanism described in the linked document, or a more traditional, but still preload-scannable pragma like\r\n\r\n`<meta name=\"script-compat\" content=\"es2019\">`?\r\n\r\nThis would have the advantage of solving web compatibility more generally, rather than requiring a debate and bespoke solution every time an ancient library causes problems. It would also make native prototype extension a potentially useful part of the language, instead of a compatibility footgun."},"comment":{"url":"https://api.github.com/repos/tc39/proposal-flatMap/issues/comments/371649305","html_url":"https://github.com/tc39/proposal-flatMap/issues/59#issuecomment-371649305","issue_url":"https://api.github.com/repos/tc39/proposal-flatMap/issues/59","id":371649305,"user":{"login":"jonrimmer","id":183786,"avatar_url":"https://avatars1.githubusercontent.com/u/183786?v=4","gravatar_id":"","url":"https://api.github.com/users/jonrimmer","html_url":"https://github.com/jonrimmer","followers_url":"https://api.github.com/users/jonrimmer/followers","following_url":"https://api.github.com/users/jonrimmer/following{/other_user}","gists_url":"https://api.github.com/users/jonrimmer/gists{/gist_id}","starred_url":"https://api.github.com/users/jonrimmer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jonrimmer/subscriptions","organizations_url":"https://api.github.com/users/jonrimmer/orgs","repos_url":"https://api.github.com/users/jonrimmer/repos","events_url":"https://api.github.com/users/jonrimmer/events{/privacy}","received_events_url":"https://api.github.com/users/jonrimmer/received_events","type":"User","site_admin":false},"created_at":"2018-03-08T22:37:41Z","updated_at":"2018-03-08T22:37:41Z","author_association":"NONE","body":"As to your specific objections, the discussion of 'use strict' in the document you is linked interesting. I think 'use strict' was awful, but that its problems were not unavoidable. Rather than taking it as a reason to abandon explicit versioning entirely, it should instead serve as a lesson for how to do it better.\r\n\r\n 1. It (ab)used strings as an in-band pragma, thus feeling weird or hacky to some developers.\r\n 2. It required declaration in every single script file, thus creating a frustrating burden on developers..\r\n 3. An opaque choice of words that suggests little about its actual purpose.\r\n 4. Most importantly, it doesn't actually *give* you anything as a developer. It just takes stuff away.\r\n\r\nGiven the above, it is any surprise that 'use strict' is unloved and often unadopted? 'Use strict' is a perfect example of something driven by what seems sensible to language designers, without proper consideration for developer ergonomics. It was treated as an opportunity to clear up a few warts, and nothing more.\r\n\r\nBut we can solve each of the above problems:\r\n\r\n 1. Use a proper pragma declaration mechanism, so it doesn't feel hacky.\r\n 2. Require a single declaration, achievable via the meta tag or HTTP header mechanisms I suggested.\r\n 3. Have a sensible and non-single-use naming scheme. Explicit opt-in to a particular ES version is a lot clearer than saying you want to \"use\" some notion of strictness.\r\n 4. Actually *provide* features as part of it. If developers have to opt-in to features like `flatMap` and `flatten`, then they're going to do it.\r\n\r\nNone of this is unprecedented, even on the web. Beyond the W3C proposal I linked previously, Google and others have been using feature availability as a way to drive adoption of HTTPS. Like it or not, this is the way the web is evolving, because it's the only way to move forward in a sustainable way. TC39 adopting a philosophical taboo against it for historical reasons is not helpful.\r\n\r\nI am also not sure what you mean by a \"drastically\" increased maintenance burden on website maintainers and test suite authors? I can certainly see that browser vendors will have to do some added work to support this. But with a single major ES version per year (many of which would probably *not* require a new compatibility mode), this seems manageable.\r\n\r\nWebsite maintainers would have no more or less of a burden. They would not be required to opt-in to newer versions, any more than the authors of ancient websites are required to update their sites now. The only difference would be that developers working *now* would be able to explicitly declare the version of ES their code is compatible with.\r\n\r\nTest suite authors would simply write tests against particular features. If run in a browser runtime with the pragma for the new version, those tests would pass. If run in one with a pragma for the old version, they would fail. Where is the maintenance burden?\r\n\r\nYou other points simply seem to be technical questions of design and implementation. I can't say what the interaction with realms and eval would be, but I can't see how they are insurmountable challenges to the entire concept of versioning. At the very least, there is prior art, as versioning is at the heart of how technology manages to progress while retaining backwards compatibility. For the group charged with stewarding the ES language forward to be so dead-set against even considering it seems perverse."}}
{"actor":{"display_login":"jonrimmer"}}