Dies kompiliert ohne Fehler in TypeScript 2.1.5:
%Vor%Ich würde erwarten, dass ein Fehler gemeldet wird, da die Auflösungsfunktion gemäß der Typdefinition mit einer Zeichenfolge anstelle einer Zahl aufgerufen wird.
Warum wird diese Typabweichung nicht vom TypScript-Compiler abgefangen und gemeldet?
Betrachtet man dies ein wenig mehr und verwendet stattdessen eine asynchrone Funktionsdefinition, meldet der Compiler den Typenkonflikt korrekt. Also das:
%Vor%gibt
%Vor%Warum verhalten sich diese Fälle anders?
Es sieht so aus, als würde der Compiler das korrekt abfangen, um explizit anzugeben, welche Art von Versprechen Sie zurückgeben. Das ist also ausreichend:
%Vor%worüber sich der Compiler nun beschwert:
%Vor%Ich nehme an, meine Frage ist jetzt, warum kann der Compiler dies aufgrund der Definition, die ich am Anfang dieser Frage gegeben habe, nicht herleiten?
Glücklicherweise gibt TypeScript 2.4 jetzt den korrekten Fehler für meinen ursprünglichen Code an! Es wird nun unterstützt Rückgabetypen als Inferenzziele . Diese Ankündigung hat sogar ein Codebeispiel, das dem Beispiel, das ich anfangs gab, sehr ähnlich ist.
In diesem Fall ...
%Vor% ... der Grund, warum die Lösung nicht number erwartet, ist, dass sie beim Schreiben von {} als new Promise(...) angegeben wurde, weil dies der Standardtyp von new Promise() ist. Der Compiler erlaubt dann die Zuweisung für Promise<{}> zu Promise<number> ..., die selbst fraglich ist.
In diesem Fall ...
%Vor% ... der zurückgegebene Typ ist Promise<string> und dieser stimmt nicht mit Promise<number> überein, so dass der Compiler einen Fehler auslöst.
In Ihrem Beispiel mit dem Versprechen können Sie dem Compiler sagen, dass er das Versprechen als Promise<number> definieren soll:
... was zu einem Kompilierungsfehler führt, weil string nicht number zuweisbar ist.
Tags und Links typescript