TypeScript 0.9.5 Beta

Topics: General
Nov 19, 2013 at 8:00 PM
In case you didn't see the secret announcement, a 0.9.5 beta was released. Is there going to be a blog post on the work this release encompasses other than the breaking changes list? This is one of the longest periods between releases you guys have had in quite a while- it would be nice to get a better idea of what to expect/look out for.
Nov 19, 2013 at 8:45 PM
I was just about to post to the forums, so you beat me to it :)

The breaking change notice (https://typescript.codeplex.com/wikipage?title=Known%20breaking%20changes%20between%200.8%20and%200.9&referringTitle=Documentation) is the best place to get what's changed between releases. We try to keep it up to date with code samples as to what's changing and cover why it's changing.

Is there something it doesn't cover that you wanted covered in more detail?

We'll do a more complete blog post to go along with the 0.9.5 release when it goes out. This is just the "beta", to get some early feedback before we put out the release. Sorry if the naming is a little confusing.
Nov 19, 2013 at 8:52 PM
A few things I'd be interested in knowing:
  • Has that restriction on self-referencing generics been removed yet or is that still in the pipeline for 1.0?
  • In what scenarios should we expect to see better performance?
  • What remains to be done to get to 1.0?
  • Specifically, what areas of the compiler have undergone significant changes? I think knowing this can help people better diagnose bugs they may encounter.
Nov 19, 2013 at 8:55 PM
I was just about to say that this is merely the Beta for the Alpha. That's not confusing at all!

@jonturner, apparently there have been some changes to index signatures that I couldn't find on your blog.
Nov 19, 2013 at 10:32 PM
Has that restriction on self-referencing generics been removed yet or is that still in the pipeline for 1.0?
The restriction has been removed.
In what scenarios should we expect to see better performance?
There have been several across-the-board performance fixes that should improve virtually any scenario. For reference, one of our internal codebases has gone from 70 seconds to just under 38. Running all the unit tests has gone from 5:21 to 3:38. The majority of the really bad performance scalability bugs (e.g. compiling linq2ts) have been fixed.
What remains to be done to get to 1.0?
Mostly bugs. There aren't any big features left to implement.

I don't have a good comprehensive list of language changes at the moment. We'll be updating the breaking changes page as people bring up issues (e.g. the index signature thing).
Nov 19, 2013 at 10:39 PM
Thanks for the information. I appreciate all the hard work you guys have done. Looking forward to trying this release out.
Nov 19, 2013 at 11:58 PM
@nabog - good catch. I've updated the list.
Nov 20, 2013 at 9:07 PM
Hi, guys,

So far the 9.5 beta is looking pretty stable. Some feedback from my team.
  • The status bar message "Output(s) generated successfully" is very useful.
  • The ordering of overloads is not a big deal in terms of maintenance.
  • A number of new implicit any cases were picked up, for instance where an inline function instead of lambda was being used, and also for lambda parameters.
  • A number of cases where generic parameters were missing was also picked up. However, I believe this can be tightened further.
  • Cases where enum types were provided where an enum value is required were identified.
  • Noticed a tighter enforcement of equality comparison where the types are not structurally compatible.
  • Picked up a few new re-declarations of a variable to a different type.
A few really nasty bugs, generally to do with generics, also seem to have been fixed.

One change that is proving to be a nuisance is that some build errors are being reported one at a time. So when a breaking change is made, it's turning into a case of fixing the error (the only one displayed) then building the project, only to find a second error cropping up.

Nov 20, 2013 at 11:33 PM
It seems that another breaking change that wasn't documented is setters and getters for properties.
        public get GridLineColor(): Color {
            return this._gridLineColor;
        public set GridLineColor(color: any) {
            if (typeof color === "string") {
                color = new Color(<any>color);
            this._gridLineColor = color;
This is no longer valid. Overloads seem appropriate here just as constructors. since type information is removed when compiled this code should be valid.
Nov 21, 2013 at 12:02 AM
Correct, that bug was fixed. The issue here is that accessors are not like functions, they are like properties, so no overloads are possible. Consider that the .d.ts for that code is:
GridLinesColor: Color
GridLinesColor(): Color;
GridLinesColor(x: any): void;
An implementation of this type may or may not use an accessor, it may just use a property of type Color.
Nov 21, 2013 at 12:39 AM
First off: I'm really happy about these performance improvements. Great work.

The "Rest arguments are now properly checked for function arity" breaking change makes sense to me but I'm unsure about how to accommodate it in my code. I have a function that looks like this:
register(scope: any, implementation: (... args: any[]) => void, canExecute?: (...args: any[]) => boolean): string
The intention here is to place no constraints on the parameters of the lambda functions but to constrain the return types. (This is all the type safety I can take advantage of using an existing JS pattern.) Can this be done in the new release?
Nov 21, 2013 at 12:39 AM
While what you say makes sense it's still perfectly valid javascript to do the following.
var Test = {};

    Object.defineProperty(Test, "propName", {
        get: function () { return this.value; },
        set: function (value) {
            if (value instanceof Date) {
                this.value = "Date was passed in";
            } else {
                this.value = value;

Test.propName = "blah";
Test.propName = new Date();
Doing so allows us to set the underlying value based on the value passed in. It's really a shame to force the same type on a property in both a set and get since the set type doesn't actually matter and javascript allows it.
Nov 21, 2013 at 12:50 AM
I take it back. At least removing :any from the setter works. Hopefully this isn't "fixed" in a later version of typescript :)