Vérification stricte de la cohérence d'unités

[mquandalle]

cf. https://github.com/betagouv/mon-entreprise/pull/1136#pullrequestreview-498202749

Je pense que le système d'unité est maintenant suffisamment mature pour que l'on puisse le passer en "mode strict" où l'on bloque de manière plus agressive les formules incohérentes, y compris dans le cas où l'une des opérandes à une unité indéfinie.

Cas d'usage par exemple dans e5a25a4, qui ne remonte pas un problème avec la suggestion "salaire médian: 2300" (au lieu de 2300 €/mois et qui provoque un bug sur le simulateur annuel.

[johangirod]

Je suis pour, d'autant plus que les incohérence de type d'unité sont en affichée en avertissement et n'empêche pas l’exécution aujourd'hui.

On peut imaginer à l'avenir un flag strict qui fasse passer les warnings en erreurs (comme dans tout bon compilateur)

[mquandalle]

J'ai commencé à regarder ce sujet. Deux autres points :

• Si l'inférence d'unité fonctionne de manière fiable sur l'ensemble des mécanismes, on peut supprimer du langage la conversion d'unité “inline” [€/mois] (et ne garder que celle au niveau de la règle comme “unité par défaut” de la règle)
• Si une unité est définie au niveau de la règle, je pense que l'on peut accepter des suggestions sans unité et considérer que ces suggestions sont par défaut de l'unité de la règle:

  règle:
    unité: €/passager
    suggestions:
      pas cher: 10
      moyen cher: 15
      cher: 20
  

  En revanche, lever une erreur s'il n'y a pas d'unité: au niveau de la règle

Pour l'implémentation, le but est de rendre plus stricte la méthode areUnitConvertible, la gestion des unités par défaut pour les suggestions devant être géré au niveau du parsing des suggestions. Pour ce qui est des comparaisons “inline” x > 3 €/mois je pense qu'il faut obliger l'explicitation de l'unité.

[mquandalle]

cf. https://github.com/betagouv/mon-entreprise/pull/1191#discussion_r530892461 sur le calcul des conversions d'unités lors du parsage au lieu de l'évaluation