question: how can i create and return a generic function in TypeScript?

[zpdDG4gta8XKpMCd]

function flip<a, b, c>(fn: (one: a, two: b) => c): (one: b, two: a) => c {
    return function flipped(one: b, two: a): c {
        return fn(two, one);
    };
}
function of2<a, b>(one: a, two: b): [a, b] {
    return [one, two];
}
const flipped = flip(of2); // expected: <a, b>(one: b, two: a) => [a, b], actual: (one: {}, two: {}) => [{}, {}]

[jesseschalken]

When TS sees flip(of2), it has to unify (one: a1, two: b1) => c1 (from flip) with <a2, b2>(one: a2, two: b2): [a2, b2] (from of2). My guess is at this step it sees that of2 has type parameters but no information for them, so just fills them in with {}.

What you would need is for TS to lift the type parameters up a level rather than just defaulting them. That is, if any type parameters needed to be defaulted when inferring the type of an expression (eg flip(of2)), the resulting type should itself have those parameters. (More than one set of type parameters may have needed to be filled in, so their order may be arbitrary.)

I'm not sure what the broad implications of that would be, though.

[gcnew]

I took a stab at this and made a hacky implementation. It's by no means complete, but it can be used to play around with.

Current progress:

function flip<A, B, R>(f: (a: A, b: B) => R): (b: B, a: A) => R {
    return (b, a) => f(a, b);
}

function id<T>(x: T): T {
    return x;
}

function fconst<X, Y>(x: X, y: Y): X {
    return x;
}

function addStr(x: number, y: string) {
    return x + y;
}

function tagged<T extends string, Q>(tag: T, value: Q): { tag: T, value: Q } {
    return { tag, value };
}

// it was working before
const f1 = flip(addStr); // (b: string, a: number) => string
const v1 = f1("hello", 3);
const v2 = id(id)(3); // `3`

// working now
const f2 = flip(id);     // <T>(b: {}, a: T): T
const f3 = flip(fconst); // <Y, X>(b: Y, a: X) => X

const v3 = f3(1, "qw") // `"qw"`
const v4 = f3([], {})  // `{}`

const f4 = flip(tagged);   // <Q, T extends string>(b: Q, a: T) => { tag: T, value: Q }
const v5 = f4(5, "hello"); // { tag: "hello", value: number }
const v6 = f4(5, 5);       // Error as expected

declare function compose<A, B, C>(f: (b: B) => C, g: (a: A) => B): (a: A) => C;

declare const f: <T>(x:number) => T;
declare const g: (x:boolean) => number;
const f5 = compose(f, g)      // OUCH! this gets type `<T>(a: boolean) => T`

declare const g_2: <T>(x: T) => boolean;
declare const f_2: (x: boolean) => number;
const f6 = compose(f_2, g_2)  // <T> (a: T) => number
const f7 = compose(id, x => String(x)) // (a: {}) => string

// Was working, now not:
declare function h<R>(f: (x: number) => R): R;
var z: number = h(id);  // number ~ T, R ~ T
                        // backpropagation is now broken

const arr = [1, 2, 3].map(id); // T[]     Snap :(

See https://github.com/gcnew/TypeScript/tree/polyFuncUnification

Edit: updated branch link and the examples

[gcnew]

@mhegazy What should the proposal look like?

[mhegazy]

mainly how it would be implemented. implications on different parts of the system, e.g. assignablity (isTypeRelatedTo), overload resolution, and generic argument inference.

[jesseschalken]

It works in Flow.

[KiaraGrouwstra]

Man, this is already an awesome improvement as-is, hope this could make it in.

@gcnew: what would you be expecting for f5 here? I'd be inclined to think the compiler is getting the best inference it can using the info available...

That Type argument candidate 'T' is not a valid type argument because it is not a supertype of candidate 'string'. in f7 is pretty weird though.

[gcnew]

@tycho01 Thank you!

Yes, you are right about f5. My remark is that it's wrong from a logical perspective. f7 is correct as well. {} says any type could work here (because of String(x: any) => string) and id just picks it up. It can be generalized to a type param but it won't change anything.

PS: I've pushed a fix for what you are observing on f7. Check [1, 2, 3].map(id) for the new road block.

[KiaraGrouwstra]

Hah, T[] for [1, 2, 3].map(id) huh. Don't think I'd seen that before, a generic without any binding...