For cb1 to be assignable to cb2, the callback of cb2 needs to be assignable to the callback of cb1 (contravariance). This isn't working because the following code in src/compiler/checker.ts compareSignaturesRelated around line 10564 is triggering, because the source rest type ConditionalType<T> is generic and the target rest type any[] is not:

            const sourceCount = getParameterCount(source);
            const sourceGenericRestType = getGenericRestType(source);
            const targetGenericRestType = sourceGenericRestType ? getGenericRestType(target) : undefined;
            if (sourceGenericRestType && !(targetGenericRestType && sourceCount === targetCount)) {
                return Ternary.False;
            }

I'm unsure what this code is supposed to be doing.

@ahejlsberg was working on a fix for assigning a type to a conditional type if it is assignable to the two branches.

@ahejlsberg was working on a fix for assigning a type to a conditional type if it is assignable to the two branches.

Unless I'm missing something, the code is bailing out at the point I quoted before it even tests assignability to the conditional type, so something additional will need to be done.

The conditional type is irrelevant here. The examples can be simplified to just:

declare var f1: (...args: any[]) => void;
declare var f2: <T extends any[]>(...args: T) => void;
f1 = f2;  // Ok
f2 = f1;  // Ok

declare var cb1: (cb: (...args: any[]) => void) => void;
declare var cb2: <T extends any[]>(cb: (...args: T) => void) => void;
cb1 = cb2;  // Ok
cb2 = cb1;  // Error

In the second example, the args parameter is co-variant, i.e. it is in an output position (a parameter in a callback parameter is effectively checked in the same manner as a return type). So, we're dealing with something similar to:

declare var ff1: () => any[];
declare var ff2: <T extends any[]>() => T;
ff1 = ff2;  // Ok
ff2 = ff1;  // Error

The second assignment fails because any[] is not assignable to T which seems entirely reasonable. So, I don't think there is a bug here.

@mattmccutchen The code you're looking at is indeed the place we error. It basically says that a generic rest parameter in the source must be matched by a generic rest parameter in the target, because only another generic type could be assignable here (i.e. for a source T extends any[], only a related U extends T would ever be assignable to T).

The second assignment fails because any[] is not assignable to T which seems entirely reasonable.

This is inconsistent with the behavior when the rest parameter is a non-generic tuple type. For example:

declare var cb1: (cb: (...args: any[]) => void) => void;
declare var cb2: (cb: (...args: [any]) => void) => void;
cb1 = cb2;  // Ok
cb2 = cb1;  // Ok

declare var ff1: () => any[];
declare var ff2: () => [any];
ff1 = ff2;  // Ok
ff2 = ff1;  // Error

So I think there is a bug here: either cb2 = cb1 should be an error in this example, or it should be allowed in the previous example.

@mattmccutchen that's because that effectively gets flattened to

declare var cb1: (cb: (...args: any[]) => void) => void;
declare var cb2: (cb: (arg0: any) => void) => void;

cb1 = cb2;
cb2 = cb1;

and

When comparing call or construct signatures, parameter names are ignored and rest parameters correspond to an unbounded expansion of optional parameters of the rest parameter element type.

Which is definitely an inconsistency in how tuple types and parameter lists are compared, but it seems unrelated here.

The thing is that you really don't know whether T will be instantiated with some subtype of Array<any> (e.g. imagine a MySuperCoolArray<T> which has an extra member). I do think it's reasonable to say any[] is not assignable to a T extends any[], but I'm not sure how to otherwise write the code @bterlson is aiming for.

The thing is that you really don't know whether T will be instantiated with some subtype of Array<any> (e.g. imagine a MySuperCoolArray<T> which has an extra member).

TypeScript doesn't normally allow that:

interface MySuperCoolArray<E> extends Array<E> { 
    hello: number;
}

// Error: A rest parameter must be of an array type.
declare var cb2: (cb: (...args: MySuperCoolArray<any>) => void) => void;

So in principle, when we see:

declare var cb2: <T extends any[]>(cb: (...args: T) => void) => void;

we should have a constraint that T be an array or tuple type. TypeScript has no way to express such a constraint, but IMO the least bad thing we can do is allow an any[] rest parameter to be assigned to a T rest parameter, like we allow it to be assigned to any specific type that is a valid type for a rest parameter.

As an aside, this isn't an error on the playground and it probably should be:

interface MySuperCoolArray<E> extends Array<E> { 
    hello: number;
}

declare var cb2: <T extends MySuperCoolArray<any>>(cb: (...args: T) => void) => void;

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.