Comprendre les avertissements en mode strict

> Tutoriel LeekScript

Vous avez décidé de passer au mode strict, et l'éditeur vous inonde de multiples avertissements qui n'existaient pas auparavant. Pas de panique, c'est tout l'intérêt du mode strict d'être moins permissif et de laisser moins de liberté sur le typage surtout. Voyons quelques cas courants d'avertissements remontés, pour comprendre quel est le problème remonté déjà, et trouver des solutions pour y remédier.

Conversion dangereuse de type « real » vers « integer »

Un premier cas simple : je veux stocker le résultat d'un calcul dans une variable de type entier.

Le problème ici est que la fonction sqrt renvoie toujours une valeur de type réel, même si mathématiquement sqrt(4) vaut 2. Or un nombre réel ne rentre pas sans perte dans une variable de type entier : que faire des décimales de sqrt(2) par exemple ? Le compilateur demande donc de faire un choix explicite. Différentes solutions existent pour résoudre cet avertissement :

Conversion dangereuse de type « integer? » vers « integer »

Autre cas : j'ai un tableau associatif (Map) de nombres entiers défini comme suit et je veux stocker une valeur de ce tableau associatif dans une variable de type entier également, normalement les types devraient concorder...

Pourquoi l'avertissement nous dit que mapEntier[0] est de type «integer?» et pas «integer» simplement ? Pour rappel, le «?» à la fin d'un type signifie que ce type accepte également les valeurs null, c'est un équivalent de «integer | null». Donc pourquoi mon tableau associatif pourrait me retourner une valeur null, alors qu'il ne contient que des integer d'après son type ? Quand on veut lire une valeur dans un tableau associatif il faut lui passer une clé, ici «0» passé entre crochets, cette clé doit être du type défini dans le tableau associatif, ici un integer, donc tout va bien à ce niveau. Mais rien ne garantit à l'éditeur l'existence de la clé dans le tableau associatif, et si on lit un tableau associatif avec une clé qui n'existe pas le retour sera toujours null. Donc le retour d'un accès à un tableau associatif par sa clé sera toujours nullable. Maintenant voyons comment résoudre ce problème pour ne plus avoir d'alertes :

Conversion dangereuse de type « (Array, Function any>) » vers « () »

Dans ce cas, j'ai une liste d'entiers que je veux trier, a priori rien de bien complexe, je reprends même l'exemple de la doc

Je me retrouve pourtant avec 2 avertissements sur cette simple ligne, commençons par le premier : il est entouré par des parenthèses, ce qui signifie que le problème se situe au niveau des paramètres de la fonction qui ne respectent pas la signature attendue. Regardons la documentation d'arraySort pour voir sa signature : Function real | integer> => Array> C'est donc une fonction qui attend 2 paramètres, une liste en premier paramètre, et en second paramètre une fonction qui prend aussi 2 paramètres et qui renvoie un entier ou un réel. En premier paramètre on lui passe bien une liste, pas de souci à ce niveau, c'est donc au niveau du second paramètre que quelque chose ne va pas, on passe une fonction avec comme signature Function any>, alors que arraySort attend Function real | integer>, le type de retour n'est pas celui attendu.

Le problème de typage de la fonction de callback est résolu, reste maintenant le second avertissement à résoudre. Comme vu juste avant, le retour de la fonction arraySort, n'est pas un Array\ comme on attend pour notre variable mais simplement Array, il faut donc caster le retour explicitement pour corriger ce problème.