Repository navigation
Type assertion error should say something about assertion rule #10360
Description
TypeScript Version: master branch
Code
interface Foo {
bug(): PromiseLike<number>;
bar(): void;
}
var foo = {
bug: () => new Promise<number>((resolve, reject) => { })
} as Foo
// Type '{ bug: () => Promise<number>; }' cannot be converted to type 'Foo'.
// Property 'bar' is missing in type '{ bug: () => Promise<number>; }'.Expected behavior:
Type assertion should work here. The error message should say about the assertion rule.
Activity
[-]TS incorrectly requires full interface implemention[/-][+]TS incorrectly requires full interface implemention for type assertion[/+][-]TS incorrectly requires full interface implemention for type assertion[/-][+]TS requires full interface implemention for type assertion[/+][-]TS requires full interface implemention for type assertion[/-][+]Type assertion requires full interface implemention [/+]yortus commentedon Aug 16, 2016
As I understand it, type assertions require one of the types to be assignable to the other, either way. In your example, neither the
foovalue or theFootype are assignable to the other, so the type assertion fails.To make that clearer, here are the equivalent types and related assignments:
Type assertions in the spec
saschanaz commentedon Aug 16, 2016
Troy Gerwien (@yortus) Ah thanks, that is understandable. But then I think the error message here is confusing as it does not say anything about the type assertion rule.
[-]Type assertion requires full interface implemention [/-][+]Type assertion error should say something about assertion rule[/+]RyanCavanaugh commentedon Aug 16, 2016
I don't think every error message should recite the relevant spec section, but we do see this reported fairly often.
Would something like this be useful?
saschanaz commentedon Aug 16, 2016
That is helpful :D
DanielRosenwasser commentedon Aug 24, 2016
While "assert" reflects the name of the syntactic form ("type assertions"), I wonder if "treat ... as" is more understandable.
duanyao commentedon Dec 16, 2016
For type assertion error, I usually found that the fix suggestions ("Property 'p' is missing in 'T'") misleading.
By definition, if types T and U are not either-way-assignable, there must be
(1) some properies only exists in T and some properies only exists in U, or
(2) same properies with types that are not either-way-assignable, or
(3) some properies only exists in T and some properies in T which are not assignable to same properies in U.
The actual fix for type assertion error may be done on T or U, or both, by adding or removing propertys, or changing the assertion itself, but the compiler only suggests one approach.
I suggest not providing fix suggestions, instead just pointing out the properties in trouble.
If some properies only exists in T and some properies only exists in U, the error messsage could contain:
"Properties only in T: x, y, z; properties only in U: a, b, c."
Else if same properies with types that are not either-way-assignable, the error messsage could contain:
"Property 'foo' has types not assignable either way. (Recusively explain why types of 'foo' are not either-way-assignable...)"
Else if some properies only exists in T and some properies in T is not assignable to same properies in U, the error messsage could contain:
"Properties only in T: x, y, z; property 'a' in T with type V is not assignable to to same property in U with type W. (Recusively explain why V is not assignable to W.)"
So the error message of the first test case in this thread could be:
I also suggest that the compiler assigning a random type name(e.g.
__T1__) to each anonymous type, to make the error message more concise.mattmccutchen commentedon Oct 10, 2018
I believe this has been addressed by #25541.
saschanaz commentedon Oct 10, 2018
I can confirm that the message has been updated:
I'll close this issue, feel free to open a new one (and link back) to give more suggestions. 👍