{"id":7191,"date":"2019-06-15T08:28:16","date_gmt":"2019-06-15T08:28:16","guid":{"rendered":"http:\/\/putridparrot.com\/blog\/?p=7191"},"modified":"2019-06-15T08:28:16","modified_gmt":"2019-06-15T08:28:16","slug":"typescripts-never-type-whats-the-point","status":"publish","type":"post","link":"https:\/\/putridparrot.com\/blog\/typescripts-never-type-whats-the-point\/","title":{"rendered":"TypeScript’s never type, what’s the point ?"},"content":{"rendered":"

At first the never<\/em> type may seem a slightly odd, possibly even pointless type. It can be used to denote that a function never returns, such as an infinite loop or a function simply throws an Error, hence again, never returns. These use cases don’t seem that useful, but you get the idea. The never<\/em> type denotes that something should never occur. <\/p>\n

Where never<\/em> becomes a lot more useful is in situations where something should never occur in your application’s control flow, specifically regarding choice operators such as switch<\/em> statements and if..else<\/em> when used for exhaustive checks.<\/p>\n

Let’s look at an example of this…<\/p>\n

You have an type Choice which is currently made up of a union of three values, which looks like this<\/p>\n

\r\ntype Choice = 'A' | 'B' | 'C';\r\n<\/pre>\n
Let’s now create a simple function which returns a string based upon the choice value<\/p>\n
\r\nfunction makeChoice(choice: Choice) {\r\n  switch(choice) {\r\n    case 'A': return 'A selected'\r\n    case 'B': return 'B selected'\r\n    case 'C': return 'C selected'\r\n  }\r\n  \/\/ should never reach\r\n}\r\n\r\nmakeChoice('C');\r\n<\/pre>\n
We’re handling all the possible values of the union and all is fine with the world. <\/p>\n
TypeScript correctly transpiles the code and if we mistakenly replace the change makeChoice(‘C’)<\/em> to makeChoice(‘D’)<\/em> (not included in the union) TypeScript reports the error Argument of type ‘”D”‘ is not assignable to parameter of type ‘Choice’<\/em>. <\/p>\n
What happens is – if we had a default<\/em> case or if the options within the switch were exhausted and the instruction pointer made it to the comment part of the function – which in this case should never occur (as all values in the union are handled). This is where the never<\/em> type comes in once all options are exhausted the choice variable in essence becomes a type never<\/em>. I know, it seems strange, but read on…<\/p>\n
So, what if we add a new value to the Choice union, let’s say ‘D’, then we have a bit of a problem, TypeScript will transpile without error but our case statement is not handling the new value and hence this may get into production without warning.<\/p>\n
Let’s make this a little more obvious by changing our code to this<\/p>\n
\r\nfunction makeChoice(choice: Choice) {\r\n  switch(choice) {\r\n    case 'A': return 'A selected'\r\n    case 'B': return 'B selected'\r\n    case 'C': return 'C selected'\r\n  }\r\n  let c: never = choice;\r\n}\r\n<\/pre>\n
Note: Assuming unused variables are not set as errors in your preferred linter then everything will compile and appear without error.<\/em><\/p>\n
What’s happening here is that the transpiler knows that all choice options are exhausted, hence choice (if you like) changes to become of type never<\/em>. Hence the line of code  let c: never = choice;<\/em> is valid as this line\/instruction should never occur. <\/p>\n
What happens it we add a new choice, so we now add ‘D’ to the Choice union and TypeScript will now report an error. This is because the choice<\/em> variable may now have another value which is not handled by the switch statement and we’ll get the following error “Type ‘”D”‘ is not assignable to type ‘never'”. Which is good because now when we transpile time we’ll be alerted to a potential issue. <\/p>\n
Prior to adding the let c: never = choice<\/em> if we transpile the code to JavaScript we get the following code, which if we change ‘C’ to ‘D’ will not report any problem (which could be fine or could be bad depending upon our usage).<\/p>\n
\r\nfunction makeChoice(choice) {\r\n   switch (choice) {\r\n      case 'A': return 'A selected';\r\n      case 'B': return 'B selected';\r\n      case 'C': return 'C selected';\r\n   }\r\n}\r\nmakeChoice('C');\r\n<\/pre>\n
So what we really want to do in our TypeScript file is throw an Error in place of the let c: never = choice<\/em>, then this will catch non-exhaustive switch statements and will be transpiled into JavaScript to give us a runtime guard to highlight a potential issue. <\/p>\n
Let’s create a simple function to handle this so our code now looks like this<\/p>\n
\r\nfunction unreachable(param: never): never { \r\n   throw new Error('should not reach here')\r\n}\r\n\r\nfunction makeChoice(choice: Choice) {\r\n  switch(choice) {\r\n    case 'A': return 'A selected'\r\n    case 'B': return 'B selected'\r\n    case 'C': return 'C selected'\r\n  }\r\n  unreachable(choice);\r\n}\r\n<\/pre>\n
which transpiles to almost exactly the same code.<\/p>\n
As the function unreachable<\/em> never returns, we mark it as such by using the never<\/em> return type.<\/p>\n
If we now try to pass ‘D’ to the function makeChoice<\/em> in the JavaScript code, an exception will occur so we’re covered at runtime now as well as at tranpsile time.<\/p>\n
Another example of using never<\/em> is in the type NonNullable<\/em> which is part of TypeScript.<\/p>\n
\r\ntype NonNullable<T> = T extends null | undefined ? never : T;\r\n<\/pre>\n
In this instance if the generic type T is null or undefined then never<\/em> is returned, hence the following type will actually be of type never<\/em> and this not assignable to<\/p>\n
\r\ntype A = NonNullable<null>;\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
At first the never type may seem a slightly odd, possibly even pointless type. It can be used to denote that a function never returns, such as an infinite loop or a function simply throws an Error, hence again, never returns. These use cases don’t seem that useful, but you get the idea. The never […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[46],"tags":[],"class_list":["post-7191","post","type-post","status-publish","format-standard","hentry","category-typescript"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/7191","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/comments?post=7191"}],"version-history":[{"count":5,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/7191\/revisions"}],"predecessor-version":[{"id":7209,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/7191\/revisions\/7209"}],"wp:attachment":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/media?parent=7191"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/categories?post=7191"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/tags?post=7191"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}