{"action":"created","issue":{"url":"https://api.github.com/repos/Microsoft/TypeScript/issues/7426","repository_url":"https://api.github.com/repos/Microsoft/TypeScript","labels_url":"https://api.github.com/repos/Microsoft/TypeScript/issues/7426/labels{/name}","comments_url":"https://api.github.com/repos/Microsoft/TypeScript/issues/7426/comments","events_url":"https://api.github.com/repos/Microsoft/TypeScript/issues/7426/events","html_url":"https://github.com/Microsoft/TypeScript/issues/7426","id":139097459,"number":7426,"title":"[Request for feedback] Nullable types, `null` and `undefined`","user":{"login":"mhegazy","id":8000722,"avatar_url":"https://avatars.githubusercontent.com/u/8000722?v=3","gravatar_id":"","url":"https://api.github.com/users/mhegazy","html_url":"https://github.com/mhegazy","followers_url":"https://api.github.com/users/mhegazy/followers","following_url":"https://api.github.com/users/mhegazy/following{/other_user}","gists_url":"https://api.github.com/users/mhegazy/gists{/gist_id}","starred_url":"https://api.github.com/users/mhegazy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mhegazy/subscriptions","organizations_url":"https://api.github.com/users/mhegazy/orgs","repos_url":"https://api.github.com/users/mhegazy/repos","events_url":"https://api.github.com/users/mhegazy/events{/privacy}","received_events_url":"https://api.github.com/users/mhegazy/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/Microsoft/TypeScript/labels/Discussion","name":"Discussion","color":"5319e7"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":97,"created_at":"2016-03-07T21:19:05Z","updated_at":"2016-03-12T22:14:09Z","closed_at":null,"body":"With the work on Nullable types in https://github.com/Microsoft/TypeScript/pull/7140, we would like to field some user input on the current design proposal.\r\n\r\n\r\nFirst some background:\r\n\r\n## `null` and `undefined`\r\n\r\nJavaScript has two ways that developers use today to denote `uninitialized` or `no-value`. the two behave differently.  where as null is completely left to user choice,  there is no way of opting out of `undefined` , so:\r\n\r\n```ts\r\nfunction foo(a?: number) {\r\n   a // => number | undefined\r\n}\r\n\r\nfunction bar() {\r\n    if(a) return 0;\r\n}\r\n\r\nbar() // => number | undefined\r\n```\r\n`a` will always implicitly has `undefined`, and so will the return type of `bar`.\r\n\r\n## Nullability\r\n\r\nGiven the JS semantics outlined above, what does a nullable type `T?` mean:\r\n 1.  `T | null | undefined`\r\n 2.  `T | undefined`\r\n\r\n####  1.  `T | null | undefined`\r\n\r\nIt is rather subtle what `?` means in different contexts:\r\n\r\n```ts\r\nfunction bar(a: number?, b?: number) {\r\n  a // => number | undefined | null\r\n  b // => number | undefined\r\n}\r\n```\r\n\r\n#### 2.  `T | undefined`\r\n\r\nThis is more consistent, the `?` always means to `| undefined`; no confusion here.\r\n\r\n`T??` can be used to mean `T | undefined | null` or `T? | null`\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/Microsoft/TypeScript/issues/comments/195818498","html_url":"https://github.com/Microsoft/TypeScript/issues/7426#issuecomment-195818498","issue_url":"https://api.github.com/repos/Microsoft/TypeScript/issues/7426","id":195818498,"user":{"login":"RyanCavanaugh","id":6685088,"avatar_url":"https://avatars.githubusercontent.com/u/6685088?v=3","gravatar_id":"","url":"https://api.github.com/users/RyanCavanaugh","html_url":"https://github.com/RyanCavanaugh","followers_url":"https://api.github.com/users/RyanCavanaugh/followers","following_url":"https://api.github.com/users/RyanCavanaugh/following{/other_user}","gists_url":"https://api.github.com/users/RyanCavanaugh/gists{/gist_id}","starred_url":"https://api.github.com/users/RyanCavanaugh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/RyanCavanaugh/subscriptions","organizations_url":"https://api.github.com/users/RyanCavanaugh/orgs","repos_url":"https://api.github.com/users/RyanCavanaugh/repos","events_url":"https://api.github.com/users/RyanCavanaugh/events{/privacy}","received_events_url":"https://api.github.com/users/RyanCavanaugh/received_events","type":"User","site_admin":false},"created_at":"2016-03-12T22:14:09Z","updated_at":"2016-03-12T22:14:09Z","body":"# Current Status\r\n\r\nThanks everyone for the comments so far; it's been very instructive. Dan posted some notes in #7488. Here's where are after the design meeting yesterday.\r\n\r\nIn the absence of a strong consensus (possible understatement of the year), we felt it was better to not have `T?` as a type syntax sugar for now. Everything else about this feature is relatively clear and it would be problematic to have a new syntax with unclear meaning be confusing users when it first appears.\r\n\r\nAdditionally, there was a relatively good consensus that making definition file authors actually *think* (e.g. read the docs) about whether a particular function might return `null` or `undefined` is a very good thing, rather than lots of people assuming that `T?` is the right shortcut for whatever the function/property might do.\r\n\r\nExisting described behavior around optional properties and optional parameters remain unchanged, changing the implicit type of `x?: string` in those positions to `string|undefined`. Additionally, the \"possibly-uninitialized\" variable syntax (`let x?: string`) will be supported, also implying `T | undefined`.\r\n\r\nGoing forward we'll be looking at what nullability-compliant definition files on DefinitelyTyped look like. If there's significant preponderance of `T | null | undefined`, `T | undefined`, or `T | null` appearing in well-formed definition files, we can certainly revisit the topic and see if it makes sense to introduce a `T?` shortcut."}}