Weak type detection only works with object literals being passed

[ownerer]

TypeScript Version: 2.4.0

Code

interface ITest {
    optional?: string;
}

function test(param: ITest): void {

}

class Test {

}

test({ whatever: 0, optional: "" }); //<-- compiler doesn't allow this
test(test); //<-- compiler allows this
test(Test); //<-- compiler allows this
test(new Test()); //<-- compiler allows this

Expected behavior:
Passing any object of any type that doesn't match with at least one of the properties defined in the weak type, should fail.

Actual behavior:
Only object literals that don't at least partially match are not allowed to be passed.

[RyanCavanaugh]

These are the rules described in #16047. I don't remember why we allow call signatures to satisfy the weak types, but there was a reason

[sylvanaar]

Before you close it, let me add the following.

    const v1 : ITest = new Test(); //<-- compiler allows this
    const v2 : ITest = test; //<-- compiler allows this

So, it isn't just for function parameters.

[RyanCavanaugh]

@sandersn is trying to remember why we allow types with call/construct signatures to be assigned in. We had to add it for a reason.

The Test class instance is empty which is always allowed as a weak type source. As usual don't use empty classes in repros because empty types have special behavior in a lot of cases

[sylvanaar]

Yeah, agree about the Test() class, but the function is strange.

[sandersn]

Here's the test case from 548f92a

// Ctor isn't a weak type because it has a construct signature
interface Ctor {
    new (s: string): K
    n?: number
}
let ctor: Ctor = K

// Ctor is similar to the more common type:
class C {
    constructor() { }
    static n?: number;
}

Ctor doesn't look weak to me, and by extension a similar function+optional properties type should also not be weak. Let me look at your example more closely to see if it changes my mind.

[sandersn]

@RyanCavanaugh the question that @ownerer raises isn't whether ITest is weak (it clearly is), but whether function test or class Test should raise weak errors when compared to it. I think they should, but it doesn't depend on whether or not they are weak types. I'll look at the code again to see why they don't.

[sandersn]

There's just an ad-hoc filter getPropertiesOfType(source).length > 0 that prevents errors for object types with no properties. I'll change that to prevent errors only for object types with index signatures and see if anything breaks.

[sandersn]

It turns out the check needs to be positive, so I changed it to getPropertiesOfType(source).length > 0 || getSignaturesOfType(source, SignatureKind.Call).length > 0 || getSignaturesOfType(source, SignatureKind.Construct).length > 0