{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/proposal-nullish-coalescing/issues/20","repository_url":"https://api.github.com/repos/tc39/proposal-nullish-coalescing","labels_url":"https://api.github.com/repos/tc39/proposal-nullish-coalescing/issues/20/labels{/name}","comments_url":"https://api.github.com/repos/tc39/proposal-nullish-coalescing/issues/20/comments","events_url":"https://api.github.com/repos/tc39/proposal-nullish-coalescing/issues/20/events","html_url":"https://github.com/tc39/proposal-nullish-coalescing/issues/20","id":291265109,"number":20,"title":"Strong evidence for treating null and undefined the same","user":{"login":"ljharb","id":45469,"avatar_url":"https://avatars1.githubusercontent.com/u/45469?v=4","gravatar_id":"","url":"https://api.github.com/users/ljharb","html_url":"https://github.com/ljharb","followers_url":"https://api.github.com/users/ljharb/followers","following_url":"https://api.github.com/users/ljharb/following{/other_user}","gists_url":"https://api.github.com/users/ljharb/gists{/gist_id}","starred_url":"https://api.github.com/users/ljharb/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ljharb/subscriptions","organizations_url":"https://api.github.com/users/ljharb/orgs","repos_url":"https://api.github.com/users/ljharb/repos","events_url":"https://api.github.com/users/ljharb/events{/privacy}","received_events_url":"https://api.github.com/users/ljharb/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":21,"created_at":"2018-01-24T16:08:06Z","updated_at":"2018-05-25T14:28:55Z","closed_at":null,"author_association":"MEMBER","body":"https://github.com/tc39/ecma262/pull/1069#issuecomment-360043550 demonstrates, convincingly to me, that instead of “ES6 default arguments distinguish undefined and null” *setting* a precedent, that they in fact defy it - and that this proposal (and optional chaining) should thus stick with the established precedent, continued in most of ES6, that null and undefined should be treated the same.\r\n\r\nThoughts?"},"comment":{"url":"https://api.github.com/repos/tc39/proposal-nullish-coalescing/issues/comments/392075657","html_url":"https://github.com/tc39/proposal-nullish-coalescing/issues/20#issuecomment-392075657","issue_url":"https://api.github.com/repos/tc39/proposal-nullish-coalescing/issues/20","id":392075657,"user":{"login":"claudepache","id":3309637,"avatar_url":"https://avatars2.githubusercontent.com/u/3309637?v=4","gravatar_id":"","url":"https://api.github.com/users/claudepache","html_url":"https://github.com/claudepache","followers_url":"https://api.github.com/users/claudepache/followers","following_url":"https://api.github.com/users/claudepache/following{/other_user}","gists_url":"https://api.github.com/users/claudepache/gists{/gist_id}","starred_url":"https://api.github.com/users/claudepache/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/claudepache/subscriptions","organizations_url":"https://api.github.com/users/claudepache/orgs","repos_url":"https://api.github.com/users/claudepache/repos","events_url":"https://api.github.com/users/claudepache/events{/privacy}","received_events_url":"https://api.github.com/users/claudepache/received_events","type":"User","site_admin":false},"created_at":"2018-05-25T14:28:55Z","updated_at":"2018-05-25T14:28:55Z","author_association":"NONE","body":"Because the nullish-coalescing operator may be thought, as the explainer of this repo says, as a mean ”to provide a default value”, some people may think hastily that it ought to be ”consistent” with defaults in function parameters and destructuring assignments. But use cases show something else. We design ”sugar” constructs in order to answer concrete needs, not ideological thoughts.\r\n\r\nAs it was first designed, defaults in function parameters and in destructuring had no special behaviour for `undefined`: only a missing value triggered the default, an explicit `undefined` did not. The intended behaviour was adjusted at some point, not because of some deep philosophical reason around the fine distinction between undefined and null, but in order to support common use cases related to forwarding arguments between function calls; see [the meeting notes of July 2012 TC39 meeting](https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-07/july-24.md#413-destructuring-issues) for details.\r\n\r\nNow, concerning nullish-coalescing, experience shows that an operator is needed, that makes the  distinction between ”nullish” and ”value or object of some non-nullish type”. Here, deep philosophical reason around the similarity between undefined and null is not relevant, but the fact that treating null the same way as a non-nullish value is, in most cases, unwanted, and would even make the operator plainly useless.\r\n\r\n> It just worries me that there is a push in the JavaScript world to ignore the underlying reasons why these two separate states exist\r\n\r\nAs I see it, in no way the design choice for defaults on the one hand and for nullish-coalescing on the other hand constitutes a judgement about the value of the distinction between different nullishes in JavaScript. In some cases, that distinction is handy. In other cases, that distinction is unwanted, not because of its intrinsic irrelevance, but simply because it is not the information we are looking for in this situation."}}
{"actor":{"display_login":"claudepache"}}