3 ms·
EDIT 2: This still surprises me... let promisedString: Promise<string> = new Promise<string>( resolve => { // Perfectly valid in TypeScript!
by andreypopp 9y ago
EDIT 2: This still surprises me...
let promisedString: Promise<string> = new Promise<string>(
resolve => {
// Perfectly valid in TypeScript!
resolve(undefined)
}
)
EDIT: no, I was wrong — Bluebird typings won't allow this behaviour but they force me to annotate both the binding and the Promise constructor call:
let promisedString: Promise<string> = new Promise<string>(
resolve => {
resolve(42) // type error here, ok
}
)
That's surprising TS ships with such unsafe typings for ES2015 Promise API...
Hm... no.
First, note that this is with noImplicitAny activated. You can check this in TS playground.
Then if we inspect what typings TS have for ES2015 Promises[1] and for Bluebird[2], you can clearly see that those are identical in this case..
[1]: https://github.com/Microsoft/TypeScript/blob/master/lib/lib.es2015.promise.d.ts#L33 https://github.com/Microsoft/TypeScript/blob/master/lib/lib....
[2]: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/bluebird/v2/index.d.ts#L34 https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...
- ng12 9y agoEr, I'm looking at it right now? I don't know what to tell you. error TS2322: Type 'Bluebird<{}>' is not assignable to type 'Bluebird<string>'. And if I add the type parameter to the constructor... error TS2345: Argument of type '42' is not assignable to parameter of type 'string | Thenable<string>' Re: your edit, you actually don't need that first typing. Typescript will infer the type of the promisedString.
- andreypopp 9y ago> your edit, you actually don't need that first typing. Typescript will infer the type of the promisedString Ok, but still this is confusing, it can't infer the type of RHS given the annotated LHS? Intuitively there's nothing wrong with it and Flow does that well...
- mcintyre1994 9y agoNote this is similar to c# (and thinking about it, every OO language I can think of): var cat = new Animal<Cat>(...); // yup! Animal<Cat> cat = new Animal(...); // Nope I wonder if internally ts is treating these generic-accepting classes in the same way, where the generic is required?