Typescript: les types non nullables ne jouent pas bien avec la déstructuration optionnelle (ng2)

Créé le 19 mai 2016  ·  1Commentaire  ·  Source: microsoft/TypeScript

Version TypeScript:

tous les soirs (1.9.0-dev.20160217)

Code

export interface QueryMetadataFactory {
    (selector: Type | string, {descendants, read}?: {
        descendants?: boolean;
        read?: any;
    }): ParameterDecorator;
    new (selector: Type | string, {descendants, read}?: {
        descendants?: boolean;
        read?: any;
    }): QueryMetadata;
}

Comportement prévisible:
Lors de la compilation avec des vérifications nulles strictes, je m'attendrais à ce que cela compile, car les variables déstructurées ont été marquées comme facultatives, car cela fonctionne:

export interface QueryMetadataFactory {
    (selector: Type | string, whatever?: {
        descendants?: boolean;
        read?: any;
    }): ParameterDecorator;
    new (selector: Type | string, whatever?: {
        descendants?: boolean;
        read?: any;
    }): QueryMetadata;
}

Comportement réel:
Lors de la compilation:

node_modules/@angular/core/src/metadata.d.ts(356,32): error TS2459: Type '{ descendants?: boolean | undefined; read?: any; } | undefined' has no property 'descendants' and no string index signature.
node_modules/@angular/core/src/metadata.d.ts(356,45): error TS2459: Type '{ descendants?: boolean | undefined; read?: any; } | undefined' has no property 'read' and no string index signature.
node_modules/@angular/core/src/metadata.d.ts(360,36): error TS2459: Type '{ descendants?: boolean | undefined; read?: any; } | undefined' has no property 'descendants' and no string index signature.
node_modules/@angular/core/src/metadata.d.ts(360,49): error TS2459: Type '{ descendants?: boolean | undefined; read?: any; } | undefined' has no property 'read' and no string index signatu
Bug
Source
picture opensrcery

Commentaire le plus utile

Celui-ci est à la limite. La fonction

function foo({ a, b }?: { a: number, b: number }) {
}

est en fait une erreur car l'argument que vous essayez de déstructurer pourrait être undefined . Donc, implémenter la signature exacte que vous avez dans votre exemple ne serait pas possible. Maintenant, si vous changez la déclaration en

function foo({ a, b }: { a: number, b: number } = { a: 0, b: 0 }) {
}

ce n'est plus une erreur car undefined serait remplacé par la valeur par défaut. Pourtant, du point de vue des appelants, le paramètre est toujours facultatif et si vous générez maintenant un fichier de déclaration, nous crachons la déclaration

declare function foo({ a, b }?: { a: number, b: number }): void;

ce qui provoque une erreur. Et _that_ est un bug.

En passant, je suggérerais d'éviter la déstructuration des paramètres dans les signatures de non-implémentation. Ils sont vraiment un détail d'implémentation, c'est-à-dire si l'implémentation de la fonction déstructure l'argument ou utilise simplement l'accès aux propriétés ne devrait pas vraiment concerner l'appelant. Cependant, dans le cas du fichier de déclaration, comme nous n'avons pas de nom de paramètre réel à émettre, nous émettons (à contrecœur) le modèle de déstructuration et nous devons donc corriger le bogue.

picture ahejlsberg le 19 mai 2016
👍2

>Tous les commentaires

Celui-ci est à la limite. La fonction

function foo({ a, b }?: { a: number, b: number }) {
}

est en fait une erreur car l'argument que vous essayez de déstructurer pourrait être undefined . Donc, implémenter la signature exacte que vous avez dans votre exemple ne serait pas possible. Maintenant, si vous changez la déclaration en

function foo({ a, b }: { a: number, b: number } = { a: 0, b: 0 }) {
}

ce n'est plus une erreur car undefined serait remplacé par la valeur par défaut. Pourtant, du point de vue des appelants, le paramètre est toujours facultatif et si vous générez maintenant un fichier de déclaration, nous crachons la déclaration

declare function foo({ a, b }?: { a: number, b: number }): void;

ce qui provoque une erreur. Et _that_ est un bug.

En passant, je suggérerais d'éviter la déstructuration des paramètres dans les signatures de non-implémentation. Ils sont vraiment un détail d'implémentation, c'est-à-dire si l'implémentation de la fonction déstructure l'argument ou utilise simplement l'accès aux propriétés ne devrait pas vraiment concerner l'appelant. Cependant, dans le cas du fichier de déclaration, comme nous n'avons pas de nom de paramètre réel à émettre, nous émettons (à contrecœur) le modèle de déstructuration et nous devons donc corriger le bogue.

ahejlsberg picture ahejlsberg le 19 mai 2016
👍2
Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

Roam-Cooper picture Roam-Cooper  ·  3Commentaires
zhuravlikjb picture zhuravlikjb  ·  3Commentaires
Antony-Jones picture Antony-Jones  ·  3Commentaires
seanzer picture seanzer  ·  3Commentaires
uber5001 picture uber5001  ·  3Commentaires