Named parameters/arguments in function call

[ivogabe]

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);

[basarat]

👍 but don't think it will work as proposed. Changing the call site based on type information is a bad idea (agree with the lessons here #9)

Some form of codegen at the function would be able to do this. Here's what I use personally (actually I just use || generally but wouldn't work for bool, or when 0 is a valid value):

// Only once: 
function def(value, def) {
    return (typeof value === "undefined") ? def : value;
}

/// generally
interface Body {
    weight?: number;
    height?: number;
}
function calculateBMI(body: Body= {}) {
    body.weight = def(body.weight, 0);
    body.height = def(body.height, 0);
}

It is more code but definitely better than inline comments (which are pretty fragile)

[ivogabe]

Changing the call site based on type information is a bad idea

The difference is that in this suggestion you will get an error message, and in the other issue you won't get an error. Using named arguments on a function typed any should be illegal in my opinion, since the compiler doesn't know the index of the argument with that name.

[basarat]

Using named arguments on a function typed any should be illegal in my opinion

With this I don't see any issues :)

[saschanaz]

Hmm... Why should we add the order restriction? Isn't it OK to force the compiler to correct the order?

[ivogabe]

Why should we add the order restriction?

Example:

function foo(first: number, second: number) {}
var z = 3;
function changeZ() {
    z = 8;
    return 1;
}
foo(second: changeZ(), first: z);

You would expect that the last line is the same as foo(second: 1, first: 8); and foo(8, 1). If the compiler would correct the order, the generated javascript would be:

foo(z, changeZ());

Which is the same as foo(3, 1);, not foo(8, 1). The compiler could correct that:

var __a;
foo((__a = [changeZ(), z], __a[1]), __a[0]);

But that's some ugly code in my opinion, and one of TypeScript's design goals is to "emit clean, idiomatic, recognizable JavaScript code."

[saschanaz]

Oh, I agree with that. Thank you for clarification :)

[RyanCavanaugh]

What's the behavior with rest args (f(x: string, ...y: any[])) ?

[ivogabe]

It think it should be allowed to call that function this way:

f(x: "foo", y: 3, 4, 5)

And not

f(x: "foo", y: 3, y: 4, y: 5)

[basarat]

@ivogabe The following

f(x: "foo", y: 3, 4, 5)

will confuse with the other sample (by reading it looks like d is 8,5):

foo(d: 8, 5); // e will be 5

[ivogabe]

@basarat It's allowed to write foo(d: 8, e: 5), but I don't want to force to add names to all arguments. An alternative for rest arguments would be to add three dots (f(x: "foo", ...y: 3, 4, 5)). I first didn't think about this because the name of the argument makes already clear that it can except multiple arguments:

list.insert(index: 3, values: 7, 8, 9); // values (plural) makes clear that there are multiple values coming.
// alternative:
list.insert(index: 3, ...values: 7, 8, 9);

---

I also thought about overloads, when a function has overloads, the selected overload should be used for the names in my opinion.

function overloaded(num: number): number;
function overloaded(str: string): string;
function overloaded(a: any): any { return a; }

overloaded(num: 5); // Ok
overloaded(str: 5); // Error
overloaded(a: 5); // Error

This would be very foreign from javascript requiring boilerplate overload-resolution and routing code in the target output.

[ivogabe]

@GITGIDDY Can you give an example of what you mean? This suggestion doesn't change a lot of the overload-resolution algorithm in the compiler. The only case where this is changed is:

function f(a?: string, b?: number);
function f(b: number);
function f(x?: any, y?: number) { }

f(b: 3); // Which signature is called?

In cases when multiple overloads can be used, the compiler chooses the signature that is sees first, so I think it should do the same here. There is a difference in the generated javascript:

f(void 0, 3); // first signature
f(3); // second signature

I think that there is not a lot of code that has these kind of overloads.

I didn't read carefully enough, I guess. Maybe I'm still not. But I don't see the advantage of specifying the parameter names, especially if, as you do a good job of explaining but I missed the first time, the parameter order cannot change at compile time. This is just so you can skip some non-trailing params? Intellisense does a good job of telling you which arguments map to which parameters. Overloads still all point to just one javascript function implementation.