4 ms·
For your 1st example, it's failing because by explicitly annotating `promisedString` you are widening the type from the inferred `number` to `any`. If you remov
by bcherny 10y ago
For your 1st example, it's failing because by explicitly annotating `promisedString` you are widening the type from the inferred `number` to `any`. If you remove the explicit annotation and let TS do its job, the code will fail (as expected) :).
For your second example - it's a divisive issue. I believe that a Hindley-Milner style type resolver (what Flow uses) is more usable, but there is a strong argument against it too [0].
[0] https://github.com/Microsoft/TypeScript/issues/15114 https://github.com/Microsoft/TypeScript/issues/15114
- andreypopp 10y ago> by explicitly annotating `promisedString` you are widening the type from the inferred `number` to `any` That's something I don't understand. Isn't that incorrect behaviour? Shouldn't TS try unify RHS and LHS?
- WorldMaker 10y agoTS is trying to unify RHS and LHS. TS follows a somewhat complicated widening process to unify unannotated generics, somewhat leaning towards ease of use over strictness. Adding additional strictness checks like noImplicitAny can help catch these situation. (In this case, it doesn't help, because the resolve argument is inferred `resolve: (value: any) => void` rather than `resolve: any` which would give a clear implicit any error. Inferred any in generic callbacks sound like a good strictness test to add...) In this case in Typescript it is generally more strict to add a type annotation to the generic than the LHS: let promise = new Promise<string>((resolve) => resolve(42)) // This won't work This is as much because the inference here that matters isn't between LHS and RHS but between generic arguments and function return inference.