Repository navigation
Weak type detection only works with object literals being passed #17656
Description
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 thisExpected 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.
Activity
RyanCavanaugh commentedon Aug 7, 2017
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 commentedon Aug 7, 2017
Before you close it, let me add the following.
So, it isn't just for function parameters.
RyanCavanaugh commentedon Aug 7, 2017
Nathan Shively-Sanders (@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
Testclass 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 casessylvanaar commentedon Aug 7, 2017
Yeah, agree about the Test() class, but the function is strange.
sandersn commentedon Aug 7, 2017
Here's the test case from 548f92a
Ctordoesn'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 commentedon Aug 7, 2017
Ryan Cavanaugh (@RyanCavanaugh) the question that Timothy Degryse (@ownerer) raises isn't whether
ITestis weak (it clearly is), but whetherfunction testorclass Testshould 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 commentedon Aug 7, 2017
There's just an ad-hoc filter
getPropertiesOfType(source).length > 0that 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 commentedon Aug 7, 2017
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