Issue 1:
C# allows adding names of arguments in a function call:

CalculateBMI(weight: 123, height: 64);

See http://msdn.microsoft.com/en-us/library/dd264739.aspx

In TypeScript's source this is also done, but with comments:

emitLinesStartingAt(nodes, /*startIndex*/ 0);

Can we have named arguments in TypeScript like this:

emitLinesStartingAt(nodes, startIndex: 0);

This can add some compile time checking, for instance when you type count: 0 you will get an error.

I think we should add a restriction that the order of the arguments cannot be changed. Example:

function foo(first: number, second: number) {}
var z = 3;
foo(second: z++, first: z);

An error should be thrown on the last line, because changing the order of the arguments (to foo(z, z++)) in the generated javascript would cause unexpected behavior.

Also this can be useful for functions with lots of optional arguments:

function foo(a?, b?, c?, d?, e?) {}
foo(e: 4);
foo(d: 8, 5); // e will be 5

Generates

function foo(a, b, c, d, e) {}
foo(void 0, void 0, void 0, void 0, 4);
foo(void 0, void 0, void 0, 8, 5);

Issue 2:
Motivation

Verify inputs at application boundary.

When a Typescript application interacts with an external system (e.g. receives a Json object from a http request, or receives an object from an external library) a typical approach is to use the cast operator for the input and to assume/hope that the application receives the required type.

If/when the external system changes the assumption can be broken resulting in sometimes hard to find bugs and unhelpful runtime errors like "undefined is not a function".

These bugs are also quite hard to catch in tests since unit tests isolate the external system, only integration tests would be able to catch these scenarios.

Proposal

A new cast operator could be introduced that does structural type checking at runtime.

Example:

$http.get('https://mySite.com/products', ( result: { data: IProduct[] } ) =>{
var data:IProduct[] = dynamic_cast<IProduct[]>result.data;
});

The Typescript compiler could operate in 2 modes ( debug / release or runtime type checks on/off)

In release the compiler would simply remove the dynamic_cast operator.

In debug mode the compiler would wrap the expression in a typeCheck call. It would generate something like this:

$http.get('https://mySite.com/products', function( result ) {
var data:IProduct[] = IProduct.CheckType(result.data);
});

The tricky bit comes in implementing the CheckType() function.

Interfaces that are dynamically checked would suddenly acquire a runtime footprint.

Also any interface and Type that appear as the type of members of any interface and type that are type checked would also need to receive a ChekType static member function.

It would be still nicer if it would be possible to support a syntax like:

$http.get('https://mySite.com/products', ( result: dynamic_cast<{ data: IProduct[] }> ) =>{
var data:IProduct[] = result.data;
});

Although it is not very clear (to me) where would the cast function be scoped and how it would be called, probably the lambda would be wrapped in something ugly like:

$http.get('https://mySite.com/products',
function (result){
return (function( result ) {
var data:IProduct[] = IProduct.CheckType(result.data);
})( ???.CheckType(result));
});