6 ms·

TypeScript 1.4 sneak peek: union types, type guards, and more

111 points by numo16 12y ago

inglor 12y ago
It's great to see they're implementing feedback from the community, union types are one of the longest awaited TypeScript features. It's crucial to support them - not to mention the timing: just a day after Facebook flow is released featuring typed JS and union types.
- ahmelsayed 12y ago
  that's not really the actual timeline. here is the pull request for adding union types. https://github.com/Microsoft/TypeScript/pull/824 https://github.com/Microsoft/TypeScript/pull/824 I believe all 3 teams, TypeScript, Flow, and AtScript, are working together for few things as is.
  - inglor 12y ago
    AtScript are working with TypeScript and supersets it. If you look at that TypeScipr PR, you see it closes an issue and they reference (2 months ago) Flow there.
benjaminjackman 12y ago
Union Types, done in a lightweight 'anonymous' fashion. Awesome! Some languages go the discriminated type union route. If I had to chose I would take the this over a that alternative. Typescript continues to push forward. Hopefully this leads to the construct being adopted by more languages. Rust has the heavier version, maybe they will adopt this before they release instead and then they can replace their gussied up Either/Err type with unions. Maybe someday the Scala team will see the light and we will get them as well. Sadly I am not holding my breath, adopting innovations like union types were what drew me to Scala. Something like this isn't even on the docket for the next several years at a minimum. All the innovation in syntax died following the terrible 2013 scaladays keynote that "challenged" the Scala community to suck as hard as Java by 2018. It's really a shame that martin didn't decide to just implement union types when he implemented tuples years ago, now the language is probably too ossified to ever adopt them for fear they'll be another XML.
- frowaway001 12y ago
  > Maybe someday the Scala team will see the light and we will get them as well. Sadly I am not holding my breath, adopting innovations like union types were what drew me to Scala. Something like this isn't even on the docket for the next several years at a minimum. ??? Union types are already announced and will ship in a future version of Scala. If you can't wait you can use dotc instead of scalac, and play with union types today. (A commit to share the newest scalac-backend between scalac and dotc just entered the pull request queue and should close one of the largest missing pieces.)
  - benjaminjackman 12y ago
    That's awesome! I must have missed that announcement where it will come sooner than the next several years. Can you point me to it? The last I heard was in the roadmap [http://www.scala-lang.org/news/roadmap-next http://www.scala-lang.org/news/roadmap-next] and the earliest it is to be expected is in "Don Giovanni" which is not 2.12 or 2.13 but 2.14 which is, what, 4-5 years away at this point? Unfortunately, we can't use dotc, we use Scala for a decently large project (220KLOC using wc -l) started back in the late 2.6/early 2.7 days which is gradually being ported to cross compile in ScalaJS. Having said that I will look into it for a side project. That's how our use of ScalaJS started. I had been attempting to use Typescript, but after giving it a shot, ScalaJS clearly beat it in every regard for our use cases, (well until the union types, but ScalaJs is still very very far ahead for us). Thanks for the heads up!
    - frowaway001 12y ago
      I think this is the announcement I had in mind, I'd just take the published roadmap with a grain of salt, because usually things ship when they are ready and fit into the whole picture. As seen in dotty, the basic stuff around union types is already working, so I'd be pretty surprised if it didn't ship earlier, especially because there is a demonstrated need for HLists, and shipping HLists without union types ... could be done, but why? Additionally, a lot of things mentioned in "Don Giovanni" are already ready-to-ship today (sans a few minor requirements). For instance Giovanni's 1.3, 2.1, (some parts of 2.4 already shipped with 2.11), (approaches for 5.1 were already discussed and benchmarked), 5.1/5.2 (will happen when targeting Java 10). My recommendation is to take that roadmap as a bottom line, but be prepared for drastic changes. My current guess is that if work gets done at the current speed, it might be possible to move things to earlier releases and subsequently eliminate a whole release in between, e. g. shipping the features of three releases in two. But that's all just my educated guess.
lobster_johnson 12y ago
Their union type syntax looks like Ceylon's. I rather like it. Union types with pattern matching would be the logical step, would it not? I wish for something like: match getResults() { case e: Error: ... case r: Results: ... }
- aikah 12y ago
  Here is the issue,at the end of the day,Typescript is just javascript with compile time type checking.Pattern matching would mean introducing "new" semantics which would make the compiled code much less readable than it is today. Tomorrow if I want to drop Typescript,I can,because it still outputs readable javascript.Introduce something like pattern matching and it will not be an option anymore.
  - Horusiath 12y ago
    I actually like cleanliness of Javascript generated from Typescript code. However I don't think that pattern matching would be more intrusive than, for example, module or class generation. Basically example from above could be compiled down to something like: var x = getResults(); if(x instanceof Error) { ... } else if(x instanceof Results) { ... }
  - lobster_johnson 12y ago
    All the TypeScript examples use "instanceof". That's what a pattern matching block like this would compile down to, surely. And pattern matching on literals (eg., [x|xs]) would also translate to perfectly adequate JavaScript.
- codygman 12y ago
  Have you checked out purescript[0]? 0: http://www.purescript.org/ http://www.purescript.org/
  - lobster_johnson 12y ago
    Yes, it looks quite nice. I might experiment with it for a personal project at some point. Is it easy to use NPM modules without any extra glue?
thomasahle 12y ago
var x = [1, 'world']; // x: Array<string|number> I'm not sure I wouldn't prefer this to give an error.
- Horusiath 12y ago
  Why? This is exactly what type definition describes - an array of string or numbers. If you'd like to have an either array of strings or array of numbers, you'd type: Array<string>|Array<number>
  - frowaway001 12y ago
    I think he meant that he would prefer not having to deal with an array where types are all over the place.
- tomp 12y ago
  That's the main issue with advanced type systems that feature things like union types, generics/polymorphism, subtyping... It's hard to specify the line between type inference guessing correctly what the programmer wants, and type inference now catching a programmer's bug. This is the reason that most Hindley-Milner type systems (e.g. OCaml's) don't allow recursive types (which come up e.g. for typing the Y combinator). Another example is: function equal<T>(lhs: T, rhs: T): boolean { return lhs === rhs; } var e = equal(42, 'hello'); Here, there obviously is a type for `T`: `any` (the toplevel dynamic type) or `number|string`. This problem is caused by the requirement that type inference is "complete", i.e. that it correctly infers types for all programs that have a valid typing (i.e. that would work if the programmer specified all types).
  - Retra 12y ago
    This makes me wonder what the point of writing 'var' is if it doesn't tell you the type of the variable.
    - UberMouse 12y ago
nojvek 12y ago
I get to see a lot of people giving hate to Javascript for being not a real language. But with TypeScript it really feels like a modern language to build large apps. I love how coffeescript offers high expression ability for prototyping while typescript offers scaffold so you don't shoot yourself in the foot.

111 points by numo16 12y ago

It's great to see they're implementing feedback from the community, union types are one of the longest awaited TypeScript features. It's crucial to support them - not to mention the timing: just a day after Facebook flow is released featuring typed JS and union types.

ahmelsayed 12y ago
that's not really the actual timeline. here is the pull request for adding union types. https://github.com/Microsoft/TypeScript/pull/824 https://github.com/Microsoft/TypeScript/pull/824 I believe all 3 teams, TypeScript, Flow, and AtScript, are working together for few things as is.
- inglor 12y ago
  AtScript are working with TypeScript and supersets it. If you look at that TypeScipr PR, you see it closes an issue and they reference (2 months ago) Flow there.

benjaminjackman 12y ago

Union Types, done in a lightweight 'anonymous' fashion. Awesome! Some languages go the discriminated type union route. If I had to chose I would take the this over a that alternative. Typescript continues to push forward. Hopefully this leads to the construct being adopted by more languages. Rust has the heavier version, maybe they will adopt this before they release instead and then they can replace their gussied up Either/Err type with unions. Maybe someday the Scala team will see the light and we will get them as well. Sadly I am not holding my breath, adopting innovations like union types were what drew me to Scala. Something like this isn't even on the docket for the next several years at a minimum. All the innovation in syntax died following the terrible 2013 scaladays keynote that "challenged" the Scala community to suck as hard as Java by 2018. It's really a shame that martin didn't decide to just implement union types when he implemented tuples years ago, now the language is probably too ossified to ever adopt them for fear they'll be another XML.

frowaway001 12y ago
> Maybe someday the Scala team will see the light and we will get them as well. Sadly I am not holding my breath, adopting innovations like union types were what drew me to Scala. Something like this isn't even on the docket for the next several years at a minimum. ??? Union types are already announced and will ship in a future version of Scala. If you can't wait you can use dotc instead of scalac, and play with union types today. (A commit to share the newest scalac-backend between scalac and dotc just entered the pull request queue and should close one of the largest missing pieces.)
- benjaminjackman 12y ago
  That's awesome! I must have missed that announcement where it will come sooner than the next several years. Can you point me to it? The last I heard was in the roadmap [http://www.scala-lang.org/news/roadmap-next http://www.scala-lang.org/news/roadmap-next] and the earliest it is to be expected is in "Don Giovanni" which is not 2.12 or 2.13 but 2.14 which is, what, 4-5 years away at this point? Unfortunately, we can't use dotc, we use Scala for a decently large project (220KLOC using wc -l) started back in the late 2.6/early 2.7 days which is gradually being ported to cross compile in ScalaJS. Having said that I will look into it for a side project. That's how our use of ScalaJS started. I had been attempting to use Typescript, but after giving it a shot, ScalaJS clearly beat it in every regard for our use cases, (well until the union types, but ScalaJs is still very very far ahead for us). Thanks for the heads up!
  - frowaway001 12y ago
    I think this is the announcement I had in mind, I'd just take the published roadmap with a grain of salt, because usually things ship when they are ready and fit into the whole picture. As seen in dotty, the basic stuff around union types is already working, so I'd be pretty surprised if it didn't ship earlier, especially because there is a demonstrated need for HLists, and shipping HLists without union types ... could be done, but why? Additionally, a lot of things mentioned in "Don Giovanni" are already ready-to-ship today (sans a few minor requirements). For instance Giovanni's 1.3, 2.1, (some parts of 2.4 already shipped with 2.11), (approaches for 5.1 were already discussed and benchmarked), 5.1/5.2 (will happen when targeting Java 10). My recommendation is to take that roadmap as a bottom line, but be prepared for drastic changes. My current guess is that if work gets done at the current speed, it might be possible to move things to earlier releases and subsequently eliminate a whole release in between, e. g. shipping the features of three releases in two. But that's all just my educated guess.

lobster_johnson 12y ago

Their union type syntax looks like Ceylon's. I rather like it. Union types with pattern matching would be the logical step, would it not? I wish for something like: match getResults() { case e: Error: ... case r: Results: ... }

aikah 12y ago
Here is the issue,at the end of the day,Typescript is just javascript with compile time type checking.Pattern matching would mean introducing "new" semantics which would make the compiled code much less readable than it is today. Tomorrow if I want to drop Typescript,I can,because it still outputs readable javascript.Introduce something like pattern matching and it will not be an option anymore.
- Horusiath 12y ago
  I actually like cleanliness of Javascript generated from Typescript code. However I don't think that pattern matching would be more intrusive than, for example, module or class generation. Basically example from above could be compiled down to something like: var x = getResults(); if(x instanceof Error) { ... } else if(x instanceof Results) { ... }
- lobster_johnson 12y ago
  All the TypeScript examples use "instanceof". That's what a pattern matching block like this would compile down to, surely. And pattern matching on literals (eg., [x|xs]) would also translate to perfectly adequate JavaScript.
codygman 12y ago
Have you checked out purescript[0]? 0: http://www.purescript.org/ http://www.purescript.org/
- lobster_johnson 12y ago
  Yes, it looks quite nice. I might experiment with it for a personal project at some point. Is it easy to use NPM modules without any extra glue?

thomasahle 12y ago

var x = [1, 'world']; // x: Array<string|number> I'm not sure I wouldn't prefer this to give an error.

Horusiath 12y ago
Why? This is exactly what type definition describes - an array of string or numbers. If you'd like to have an either array of strings or array of numbers, you'd type: Array<string>|Array<number>
- frowaway001 12y ago
  I think he meant that he would prefer not having to deal with an array where types are all over the place.
tomp 12y ago
That's the main issue with advanced type systems that feature things like union types, generics/polymorphism, subtyping... It's hard to specify the line between type inference guessing correctly what the programmer wants, and type inference now catching a programmer's bug. This is the reason that most Hindley-Milner type systems (e.g. OCaml's) don't allow recursive types (which come up e.g. for typing the Y combinator). Another example is: function equal<T>(lhs: T, rhs: T): boolean { return lhs === rhs; } var e = equal(42, 'hello'); Here, there obviously is a type for `T`: `any` (the toplevel dynamic type) or `number|string`. This problem is caused by the requirement that type inference is "complete", i.e. that it correctly infers types for all programs that have a valid typing (i.e. that would work if the programmer specified all types).
- Retra 12y ago
  This makes me wonder what the point of writing 'var' is if it doesn't tell you the type of the variable.
  - UberMouse 12y ago

nojvek 12y ago

I get to see a lot of people giving hate to Javascript for being not a real language. But with TypeScript it really feels like a modern language to build large apps. I love how coffeescript offers high expression ability for prototyping while typescript offers scaffold so you don't shoot yourself in the foot.