La logique booléenne est censée être simple. Vrai ou faux. Mais quand None entre en jeu, la logique booléenne développe un troisième état qui peut produire des résultats qui semblent corrects en surface tout en étant fondamentalement faux en profondeur.
Le 17 janvier 2026, la case à cocher de toggle de l'application todo avait un défaut persistant : elle pouvait marquer une tâche comme « done » mais ne pouvait jamais la démarquer. Chaque opération de toggle définissait done à true.
La cause : le générateur de code n'émettait que les champs explicitement fournis dans le constructeur d'entité. Todo { title: newTodo.trim() } omettait done, et sans la valeur par défaut false appliquée, le champ était absent. Un champ absent en FLIN s'évalue à None. !None s'évalue à true. Donc chaque toggle produisait true.
La correction a modifié emit_entity_construct() pour appliquer les valeurs par défaut pour tout champ d'entité non explicitement fourni, en consultant le schéma de l'entité.
Le principe révélé : dans un langage avec la sémantique du None, les valeurs par défaut explicites ne sont pas optionnelles -- elles sont structurellement essentielles. Un champ booléen non initialisé n'est pas false -- c'est None, qui se comporte différemment sous la négation.
Ceci est la partie 168 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont conçu et construit un langage de programmation à partir de zéro.
Navigation de la série : - [167] Bugs d'ordonnancement des entités et de format de temps - [168] Valeurs par défaut des entités et correction du toggle (vous êtes ici) - [169] La crise du choix du modèle d'embeddings