Issue 1:
(Update by @RyanCavanuagh)

Please see this comment before asking for "any updates", "please add this now", etc.. Comments not meaningfully adding to the discussion will be removed to keep the thread length somewhat reasonable.

(NOTE, this is not a duplicate of Issue #1524. The proposal here is more along the lines of the C++ override specifier, which makes much more sense for typescript)

An override keyword would be immensely useful in typescript. It would be an optional keyword on any method that overrides a super class method, and similar to the override specifier in C++ would indicate an intent that "the name+signature of this method should always match the name+signature of a super class method". This catches a whole range of issues in larger code bases that can otherwise be easily missed.

Again similar to C++, it is not an error to omit the override keyword from an overridden method. In this case the compiler just acts exactly as it currently does, and skips the extra compile time checks associated with the override keyword. This allows for the more complex untyped javascript scenarios where the derived class override does not exactly match the signature of the base class.

Example use

class Animal {
move(meters:number):void {
}
}

class Snake extends Animal {
override move(meters:number):void {
}
}

Example compile error conditions

// Add an additional param to move, unaware that the intent was
// to override a specific signature in the base class
class Snake extends Animal {
override move(meters:number, height:number):void {
}
}
// COMPILE ERROR: Snake super does not define move(meters:number,height:number):void

// Rename the function in the base class, unaware that a derived class
// existed that was overriding the same method and hence it needs renaming as well
class Animal {
megamove(meters:number):void {
}
}
// COMPILE ERROR: Snake super does not define move(meters:number):void

// Require the function to now return a bool, unaware that a derived class
// existed that was still using void, and hence it needs updating
class Animal {
move(meters:number):bool {
}
}
// COMPILE ERROR: Snake super does not define move(meters:number):void

IntelliSense

As well as additional compile time validation, the override keyword provides a mechanism for typescript intellisense to easily display and select available super methods, where the intent is to specifically override one of them in a derived class. Currently this is very clunky and involves browsing through the super class chain, finding the method you want to override, and then copy pasting it in to the derived class to guarantee the signatures match.

Proposed IntelliSense mechanism

Within a class declaration:

type override

An auto complete drop down appears of all super methods for the class

A method is selected in the drop down

The signature for the method is emitted into the class declaration after the override keyword.

Issue 2:
I noticed that recently a lot of new APIs are added to lib.d.ts. Of cause this is a good thing, however my code breaks badly because of such update.

Previously I had added a lot of declarations in my code for HTML5 APIs that were missing in lib.d.ts . Now some of them are added to lib.d.ts, and I get quite a few "duplicated identifier" errors. For example, I had added this piece to play with fullscreen:

interface Document {
//...
fullscreenEnabled: boolean;
mozFullScreenEnabled: boolean;
webkitFullscreenEnabled: boolean;
}

Now fullscreenEnabled and webkitFullscreenEnabled are available in lib.d.ts, and my code breaks, and I have to remove them. However, you are still missing mozFullScreenEnabled right? -- well, waiting for the next break.

Web platforms are constantly evolving, it is not practical to expect lib.d.ts always up to date, so developers just have to write such compensating declarations from time to time. Can TS avoid such breaks? I have a few ideas:

Allow duplicated members in multiple interface declarations, as long as they are identical. In the fullscreen API example above, tsc should not fire errors. Optional compiling warnings are acceptable, to assist developers to remove redundant codes at convenient time.

Make lib.d.ts overridable. When tsc find conflictions between lib.d.ts and client codes, it should pickup declarations in client codes. This is because declarations lib.d.ts may contain bugs, developers should be allowed to workaround them. E.g. MutationObserver's constructor was missing a parameter for a long time. Again, optional warnings are welcomed.

What do you think?