bind(), call(), and apply() are untyped

[jameslong]

bind() returns type 'any' and does not type check it's arguments. e.g.

var add = function (a: number, b: number) { return a + b; };
var addString = add.bind(null, 'hello');

compiles without error and 'addString' has type any.

bind is a default way to achieve partial application so it would be great to have it typechecked properly.

Similarly for apply, the code

var listA = [1, 2, 3];
var listB = ['a', 'b', 'c'];
listA.push.apply(listA, listB);

compiles without error and listA is still incorrectly marked as type 'number[]'.

call() example:

var add5 = function (a: number) { return 5 + a; };
add5.call(null, 'a string');

Again without a compiler error.

[danquirk]

It would be nice to type these more strongly but we will need a proposal for some options. We previously discussed this in some early design meetings on generics and weren't really able to come up with something suitable. At least using Function instead of 'any' where applicable might be a meaningful improvement. See Ander's response here for a similar example: https://typescript.codeplex.com/discussions/462819

This will return you a function with the same signature you passed in--and for memoize that's really the thing that matters. There's no generic way to extract the parameters and/or return type from a function type, so the hashFn parameter is probably best left as just Function.

[jameslong]

With regards to 'bind' and 'call', what specifically do you need proposals for? Are there cases where the returned type could be ambiguous? Apologies if I'm missing something obvious.

[RyanCavanaugh]

Just a brief exploration of some of the issues here. We would need to fill in all the ?s along with descriptions of how those results would be achieved.

interface fn {
    (): string;
    (n: number): void;
    (n: number, m: number): Element;
    (k: string): Date;
}

var x: fn;
var y = x(); // y: string

var args = [3]; // args: number[]
var c1 = x.apply(window, args); // c1: ?
args = []; // arg: still number[]
var c2 = x.apply(window, args); // c2: ??

var b = x.bind(undefined, null); // b: what type?
var j = b(); // j: ?

call is less difficult to reason about, but it's probably the most unlikely to be used in a place where you'd need strong type information.

[zpdDG4gta8XKpMCd]

It seems like the apply method of a function just cannot return a typed value.
In order to determine the type we have to find a mapping of an array (arguments) to a number of tuples (parameters of different signatures from overloads). It can only be done if we know the number of elements in the array and their types. Having these 2 things we can view the array as a tuple. Matching tuples to tuples is a solvable problem. Now in order to know the number of elements in an array and their type at the compile time it has got to be an array literal (not an expression). Only in this case we can deduce the type, but restricting apply to array literals only would be a significant and pointless limitation. All this means that in order to have a typed version of apply there has to be a different syntax that takes array literals, or just tuples straight, and deduces the type of the result. In order not to introduce new syntax there can be a typed overload of apply that takes an array literal or just a list of arguments as they listed in the original function. Even when the original signature of a function matches the one of the apply method of that function it should not be a problem. In this case there will be no overloads, but just one single way to call it which is what it has now.

// typescript
f(a: number, b: string) {}
f.apply(<any>null, 10, 'hey');

// emitted javascript
f(a, b) {}
f.apply(null, [10, 'hey'])

[Airblader]

Here is another example I came across where this is an issue:

interface Entity {}

class Example { 
    constructor( private lines: string[] ) {}

    mapLines(): Entity[][] {
        return this.lines.map( this.mapLine.bind( this ) ); 
    }

    mapLine( line: string ): Entity[] {
        return line.split( '' ).map( this.mapCharacter.bind( this ) );
    }

    mapCharacter( character: string ): Entity {
        return {};
    }
}

var instance = new Example( ["foo", "baz"] );
instance.mapLines();

The binds are needed because of the usage of this, but since bind returns any, the compiler will error out because of the mismatch of Entity{}[] and Entity[][].

The only solution I could think of is to force the type:

return <Entity[][]>this.lines.map( this.mapLine.bind( this ) );

[psnider]

@RyanCavanaugh
regarding:

call is less difficult to reason about, but it's probably the most unlikely to be used in a place where you'd need strong type information.

I find I have a lot of trouble with this issue, as I frequently factor my functions so that they contain small helper functions. Here's a simplified example to show the structure I use:

interface Options {a: string;}

class A {
    local: string;
    f(options: Options) {
        function helper(options: Options) {
            this.local = options.a;
        }
        helper.call(this, {b: ''}); // the error here is not reported by the compiler
    }   
}

Any helpers that reference this must be invoked via call().
This problem hits me hard when I refactor code, including renaming variables, which I do frequently as I come up with better naming.

I would greatly appreciate it if you could add support for type checking the arguments of a call().
(I also understand that apply() has too many ambiguities to support type checking).

EDITED: to add type helper

[DanielRosenwasser]

@psnider, if you want to avoid introducing a lexical this, you could explicitly capture the outer one

var _this = this;
function helper(opts: Options) {
    _this.a = // ...
}

or you could also use an arrow function.

var helper = (opts: Options) => {
    this.a = // ...
}

[psnider]

@DanielRosenwasser

awesome! Cleans things up nicely, solving two problems:

• removes the need for call()
• gives me back the nice type checking that I love TypeScript for

Thanks, I had overlooked using the fat-arrow syntax here,
although I use it all the time for callbacks and promises.

I can continue on with my refactoring addiction without fear!

For reference, the modified code, for which the compiler correctly reports the type error is:

interface Options {a: string;}

class A {
    local: string;
    f(options: Options) {
        var helper = (options: Options) => {
            this.local = options.a;
        }
        helper(this, {b: ''});
    }   
}

[jameslong]

Ok how about this as a spec for bind:

Binding with:

• args which do not match the original function type
• too many args

results in compiler error: 'Supplied parameters do not match any signature of call target.' e.g.

var x: (a: typeA, b: typeB, c: typeC): returnType;
var a: typeA;
var b: typeB;
var c: typeC;
var d: typeD;

var boundX = x.bind(undefined, a, b, d); // COMPILER ERROR
var boundX' = x.bind(undefined, a, b, c, d); // COMPILER ERROR

For an overloaded function where there is ambiguity, 'bind' should return type any. e.g.

interface fn {
    (): string;
    (n: number): void;
    (n: number, m: number): Element;
    (k: string): Date;
}

var x: fn;
var boundX = x.bind(undefined, null); // boundX: any

For:

• a function which is not overloaded
• a function which is overloaded but bind is called unambiguously

bind returns the expected typed value:

var x: (a: typeA, b: typeB, c: typeC): returnType;
var a: typeA;
var b: typeB;

var boundX = x.bind(undefined, a); // boundX: (b: typeB, c: typeC): returnType;
var boundX' = x.bind(undefined, a, b); // boundX': (c: typeC): returnType;

interface fn {
    (): string;
    (n: number): void;
    (k: string): Date;
}

var y: fn;

var boundY = y.bind(undefined, 5); // boundY: (): void
var boundY' = y.bind(undefined, 'a string'); // boundY': (): Date

[DanielRosenwasser]

@psnider glad that solves your problem!

Now that we have tuple types, my personal opinion is that instead of trying to add magic to the typing for these functions, you should actually use typed functions.

var _apply = (f: any, args: any[], thisArg?: any) => f.apply(thisArg, args);
var apply$: <T, R>(f: (...values: T[]) => R, args: T[], thisArg?: any) => R = _apply
var apply2: <T1, T2, R>(f: (a1: T1, a2: T2) => R, args: [T1, T2], thisArg?: any) => R = _apply
var apply3: <T1, T2, T3, R>(f: (a1: T1, a2: T2, a3: T3) => R, args: [T1, T2, T3], thisArg?: any) => R = _apply;
var apply4: <T1, T2, T3, T4, R>(f: (a1: T1, a2: T2, a3: T3, a4: T4) => R, args: [T1, T2, T3, T4], thisArg?: any) => R = _apply;
var apply5: <T1, T2, T3, T4, T5, R>(f: (a1: T1, a2: T2, a3: T3, a4: T4, a5: T5) => R, args: [T1, T2, T3, T4, T5], thisArg?: any) => R = _apply;
// etc.

Or you could use overloads if you don't like explicit arities:

function apply<T1, T2, T3, T4, T5, R>(f: (a1: T1, a2: T2, a3: T3, a4: T4, a5: T5) => R, args: [T1, T2, T3, T4, T5], thisArg?: any): R;
function apply<T1, T2, T3, T4, R>(f: (a1: T1, a2: T2, a3: T3, a4: T4) => R, args: [T1, T2, T3, T4], thisArg?: any): R;
function apply<T1, T2, T3, R>(f: (a1: T1, a2: T2, a3: T3) => R, args: [T1, T2, T3], thisArg?: any): R;
function apply<T1, T2, R>(f: (a1: T1, a2: T2) => R, args: [T1, T2], thisArg?: any): R;
function apply<T, R>(f: (...values: T[]) => R, args: T[], thisArg?: any): R;
function apply(f: any, args: any[], thisArg?: any) {
    return f.apply(thisArg, args);
}

Instead of bind, it was already easy enough to write curry* and bind* doing something like I did above, or the following:

function curry2<T1, T2, R>(f: (a1: T1, a2: T2) => R) {
    return (a1: T1) => (a2: T2) => f(a1, a2);
}
function curry3<T1, T2, T3, R>(f: (a1: T1, a2: T2, a3: T3) => R) {
    return (a1: T1) => (a2: T2) => (a3: T3) => f(a1, a2, a3);
}
// etc.
function bind2<T1, T2, R>(f: (a1: T1, a2: T2) => R, thisArg: any) {
    return (a1: T1) => (a2: T2): R => f.call(thisArg, a1, a2);
}
// etc.

call* could be typed in a similar manner.

[jameslong]

@DanielRosenwasser Could you expand on why you are against my solution for bind? Do you believe your proposal will be better from a user standpoint?

As a typescript user, I want to use bind in an identical way to javascript. i.e.

myFunction.bind(undefined, arg0, arg1);

and have it typed as per my previous post. Your proposals would not support this. For example, using your solution 'bind2', the code would look like:

bind2(myFunction, undefined)(arg0);

And even worse for functions with more applied args e.g.

    bind5(myFunction, undefined)(arg0)(arg1)(arg2)(arg3);

Using bind as described in my proposal is not only more familiar to people who know javascript, but also allows easier transition from untyped javascript code into properly typed typescript.

[danquirk]

@jameslong we generally understand what the desired behavior of bind is. Your solution is stating the cases which would be errors and which would not be but that's not really the level of detail holding back this feature. We need a solution that models the type signatures and type flow in a way that allows the compiler to actually figure out whether or not to report an error in these cases.

[DanielRosenwasser]

Thanks @danquirk, that effectively describes the main issue. The other is that I'm generally not a fan of having compiler-internal support of bind. We could do a lot of compiler-internal stuff, like type-checking static strings in an eval invocation. In most cases, it's better to have a a fishing net than one really big fish (or something like that, I don't really know anything about fishing).

@jameslong, for your examples, why even bother with bind?

bind2(myFunction, undefined)(arg0)

becomes something like

(x: number) => myFunction(arg0, x)

and

bind5(myFunction, undefined)(arg0)(arg1)(arg2)(arg3)

becomes something like

(x: string) => myFunction(arg0, arg1, arg2, arg3, x)

It's not perfect, but it's not nearly the worst workaround either. If you need to specify a this argument, use the apply* functions I defined above.