Entender os avisos do modo estrito

> Tutorial do LeekScript

Você decidiu passar para o modo estrito, e o editor te inunda com vários avisos que não existiam antes. Sem pânico: é justamente esse o interesse do modo estrito — ser menos permissivo e deixar menos liberdade, sobretudo na tipagem. Vejamos alguns casos comuns de avisos, para entender primeiro qual é o problema apontado e depois encontrar soluções para corrigi-lo. (Os avisos são citados aqui tais como o editor os exibe, em francês.)

Conversion dangereuse de type « real » vers « integer »

Um primeiro caso simples: quero armazenar o resultado de um cálculo em uma variável de tipo inteiro.

O problema aqui é que a função sqrt sempre retorna um valor de tipo real, mesmo que matematicamente sqrt(4) valha 2. Ora, um número real não cabe sem perda em uma variável de tipo inteiro: o que fazer com as casas decimais de sqrt(2), por exemplo? O compilador pede, portanto, uma escolha explícita. Existem diferentes soluções para resolver esse aviso:

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

Outro caso: tenho um array associativo (Map) de números inteiros definido como segue e quero armazenar um valor desse array associativo em uma variável também de tipo inteiro; normalmente os tipos deveriam bater...

Por que o aviso diz que mapEntier[0] é do tipo «integer?» e não simplesmente «integer»? Lembrando: o «?» no fim de um tipo significa que esse tipo também aceita valores null; é um equivalente de «integer | null». Então por que meu array associativo poderia me retornar um valor null, se ele só contém integer de acordo com seu tipo? Quando queremos ler um valor em um array associativo, precisamos passar uma chave — aqui o «0» entre colchetes. Essa chave deve ser do tipo definido no array associativo, aqui um integer, então nesse ponto está tudo bem. Mas nada garante ao editor a existência da chave no array associativo, e, se lermos um array associativo com uma chave que não existe, o retorno será sempre null. Portanto, o retorno de um acesso a um array associativo pela chave sempre será anulável. Agora vejamos como resolver esse problema para não ter mais alertas:

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

Neste caso, tenho uma lista de inteiros que quero ordenar; a princípio nada muito complexo — eu até retomo o exemplo da documentação

Ainda assim, acabo com 2 avisos nesta simples linha. Comecemos pelo primeiro: ele está cercado por parênteses, o que significa que o problema está nos parâmetros da função, que não respeitam a assinatura esperada. Olhemos a documentação de arraySort para ver sua assinatura: Function real | integer> => Array> É, portanto, uma função que espera 2 parâmetros: uma lista como primeiro parâmetro e, como segundo, uma função que também recebe 2 parâmetros e retorna um inteiro ou um real. No primeiro parâmetro passamos de fato uma lista, nenhum problema nesse ponto; é então no segundo parâmetro que algo não vai bem: passamos uma função com a assinatura Function any>, enquanto arraySort espera Function real | integer> — o tipo de retorno não é o esperado.

O problema de tipagem da função de callback está resolvido; resta agora o segundo aviso. Como visto logo acima, o retorno da função arraySort não é um Array\, como esperamos para a nossa variável, mas simplesmente Array; é preciso, portanto, fazer um cast explícito do retorno para corrigir esse problema.