Cette question peut sembler stupide, mais pourquoi 0évalue-t-elle falseet toute autre valeur [entière] trueest la plupart des langages de programmation?

Comparaison de chaîne

Comme la question semble un peu trop simple, je vais en expliquer un peu plus: tout d’abord, cela peut sembler évident à tout programmeur, mais pourquoi n’y aurait-il pas un langage de programmation - il se peut qu’il en existe, mais pas n'importe lequel. J'ai utilisé - où 0évalue trueet toutes les autres valeurs [entier] à false? Cette remarque peut sembler aléatoire, mais j’ai quelques exemples où cela aurait pu être une bonne idée. Tout d'abord, prenons l'exemple de la comparaison tridirectionnelle de chaînes, je prendrai strcmpcomme exemple l'exemple de C : tout programmeur essayant d'utiliser C comme première langue peut être tenté d'écrire le code suivant:

if (strcmp(str1, str2)) { // Do something... }

Depuis strcmpreturn, 0qui évalue à falsequand les chaînes sont égales, ce que le programmeur a essayé de faire échoue lamentablement et il ne comprend généralement pas pourquoi au début. Si elle avait été 0évaluée à la trueplace, cette fonction aurait pu être utilisée dans sa plus simple expression - celle ci-dessus - pour comparer l'égalité et les vérifications appropriées pour -1et 1n'auraient été effectuées qu'en cas de besoin. Nous aurions considéré le type de retour comme bool(dans notre esprit je veux dire) la plupart du temps.

De plus, introduisons un nouveau type sign, qui prend juste des valeurs -1, 0et 1. Cela peut être très pratique. Imaginez qu'il y ait un opérateur de vaisseau spatial en C ++ et que nous le voulions std::stringbien (bon, il y a déjà une comparefonction, mais l'opérateur de vaisseau spatial est plus amusant). La déclaration serait actuellement la suivante:

sign operator<=>(const std::string& lhs, const std::string& rhs);

S'il avait 0été évalué true, l'opérateur du vaisseau spatial n'existerait même pas, et nous aurions pu le déclarer operator==ainsi:

sign operator==(const std::string& lhs, const std::string& rhs);

Cela operator==aurait traité la comparaison à trois voies à la fois, et pourrait toujours être utilisé pour effectuer le contrôle suivant tout en pouvant vérifier quelle chaîne est lexicographiquement supérieure à l'autre le cas échéant:

if (str1 == str2) { // Do something... }

Gestion des erreurs anciennes

Nous avons maintenant des exceptions, donc cette partie ne s’applique qu’aux anciennes langues où il n’en existait pas (C par exemple). Si nous regardons la bibliothèque standard de C (et celle de POSIX également), nous pouvons voir avec certitude que les fonctions maaaaany retournent en 0cas de succès et que tout nombre entier sinon. J'ai malheureusement vu des gens faire ce genre de choses:

#define TRUE 0
// ...
if (some_function() == TRUE)
{
    // Here, TRUE would mean success...
    // Do something
}

Si nous réfléchissons à notre façon de penser en programmation, nous avons souvent le schéma de raisonnement suivant:

Do something
Did it work?
Yes ->
    That's ok, one case to handle
No ->
    Why? Many cases to handle

Si nous y repenions, il aurait été logique de mettre la seule valeur neutre 0, à yes(et c'est ainsi que fonctionnent les fonctions de C), alors que toutes les autres valeurs peuvent être là pour résoudre les nombreux cas de la no. Cependant, dans tous les langages de programmation que je connais (sauf peut - être quelques langues expérimentales ésotériques), qui yesévalue à falsedans un ifétat, alors que tous les nocas à évaluer true. Il existe de nombreuses situations où "ça marche" représente un cas alors que "ça ne marche pas" représente plusieurs causes probables. Si nous y réfléchissons de la sorte, avoir 0évalué à trueet au reste falseaurait eu beaucoup plus de sens.

Conclusion

Ma conclusion est essentiellement ma question initiale: pourquoi avons-nous conçu les langages où 0sont falseet sont les autres valeurs true, en prenant en compte mes quelques exemples ci-dessus et peut-être d'autres que je n'ai pas pensé?

Suivi: Il est agréable de voir qu'il existe de nombreuses réponses avec de nombreuses idées et autant de raisons possibles pour que cela se produise. J'aime à quel point vous semblez passionné. Au départ, j’avais posé cette question par ennui, mais comme vous paraissiez si passionné, j’ai décidé d’aller un peu plus loin et de demander pourquoi le choix booléen pour 0 et 1 sur Math.SE :)

0est falseparce qu'ils sont tous les deux des éléments nuls dans les semi- communes . Même s'il s'agit de types de données distincts, il est logique de procéder à la conversion entre eux, car ils appartiennent à des structures algébriques isomorphes.

• 0est l'identité pour l'addition et zéro pour la multiplication. Cela est vrai pour les entiers et les rationnels, mais pas pour les nombres à virgule flottante IEEE-754: 0.0 * NaN = NaNet 0.0 * Infinity = NaN.

• falseest l'identité pour booléenne XOR (⊻) et zéro pour booléenne et (∧). Si les booléens sont représentés par {0, 1} - l'ensemble des entiers modulo 2 -, vous pouvez considérer comme addition sans retenue et comme multiplication.

• ""et []sont une identité pour la concaténation, mais il y a plusieurs opérations pour lesquelles elles ont un sens comme zéro. La répétition en est une, mais la répétition et la concaténation ne sont pas distribuées et ces opérations ne forment donc pas un semiring.

De telles conversions implicites sont utiles dans les petits programmes, mais dans l’ensemble, elles peuvent rendre les programmes plus difficiles à raisonner. Un des nombreux inconvénients de la conception linguistique.

Parce que les maths fonctionnent.

FALSE OR TRUE is TRUE, because 0 | 1 is 1.

... insert many other examples here.

Traditionnellement, les programmes C ont des conditions comme

if (someFunctionReturningANumber())

plutôt que

if (someFunctionReturningANumber() != 0)

parce que le concept de zéro étant équivalent à faux est bien compris.

Comme d'autres l'ont dit, le calcul est venu en premier. C'est pourquoi 0 est falseet 1 est true.

De quelles mathématiques parlons-nous? Algèbres booléennes datant du milieu des années 1800, bien avant l'arrivée des ordinateurs numériques.

Vous pouvez également dire que la convention est issue de la logique propositionnelle , qui est même plus ancienne que les algèbres booléennes. C'est la formalisation de beaucoup de résultats logiques que les programmeurs connaissent et aiment ( false || xégaux x, true && xégaux x, etc.).

Fondamentalement, nous parlons d'arithmétique sur un ensemble avec deux éléments. Pensez à compter en binaire. Les algèbres booléennes sont à l'origine de ce concept et de son fondement théorique. Les conventions de langages comme C ne sont qu’une application simple.

Je pensais que cela avait à voir avec "l'héritage" de l'électronique, et aussi l'algèbre booléenne, où

• 0= off, negative, no,false
• 1= on, positive, yes,true

strcmp renvoie 0 lorsque les chaînes sont égales, cela a à voir avec sa mise en œuvre, car ce qu'il fait est de calculer la "distance" entre les deux chaînes. Que 0 soit également considéré comme faux est simplement une coïncidence.

Il est logique de renvoyer 0 en cas de succès, car 0 signifie dans ce cas aucune erreur et tout autre chiffre constituerait un code d'erreur. Utiliser n'importe quel autre numéro pour réussir aurait moins de sens puisque vous n'avez qu'un seul code de réussite, alors que vous pouvez avoir plusieurs codes d'erreur. Vous utilisez "Cela a-t-il fonctionné?" comme si l'expression de déclaration et dire 0 = oui aurait plus de sens, mais l'expression est plus correctement "Est-ce que quelque chose s'est mal passé?" et ensuite vous voyez que 0 = non a beaucoup de sens. Penser false/truen'a pas vraiment de sens ici, comme c'est en fait no error code/error code.

Comme expliqué dans cet article , les valeurs falseet truene doivent pas être confondues avec les entiers 0 et 1, mais peuvent être identifiées avec les éléments du corps de Galois (champ fini) de deux éléments (voir ici ).

Un champ est un ensemble avec deux opérations qui satisfont certains axiomes.

Les symboles 0 et 1 sont classiquement utilisés pour désigner les identités additives et multiplicatives d'un champ car les nombres réels sont aussi un champ (mais pas un nombre fini) dont les identités sont les nombres 0 et 1.

L'identité additive est l'élément 0 du champ, tel que pour tout x:

x + 0 = 0 + x = x

et l'identité multiplicative est l'élément 1 du champ, tel que pour tout x:

x * 1 = 1 * x = x

Le corps fini de deux éléments n'a que ces deux éléments, à savoir l'identité additive 0 (ou false) et l'identité multiplicative 1 (ou true). Les deux opérations de ce champ sont le XOR logique (+) et le ET logique (*).

Remarque. Si vous inversez les opérations (XOR est la multiplication et AND est l'addition), la multiplication n'est pas distributive sur l'addition et vous n'avez plus de champ. Dans un tel cas, vous n'avez aucune raison d'appeler les deux éléments 0 et 1 (dans n'importe quel ordre). Notez également que vous ne pouvez pas choisir l'opération OR à la place de XOR: quelle que soit la façon dont vous interprétez OR / AND comme addition / multiplication, la structure résultante n'est pas un champ (tous les éléments inverses n'existent pas comme l'exigent les axiomes du champ).

En ce qui concerne les fonctions C:

• De nombreuses fonctions renvoient un entier représentant un code d'erreur. 0 signifie AUCUNE ERREUR.
• Intuitivement, la fonction strcmpcalcule la différence entre deux chaînes. 0 signifie qu'il n'y a pas de différence entre deux chaînes, c'est-à-dire que deux chaînes sont égales.

Les explications intuitives ci-dessus peuvent aider à mémoriser l'interprétation des valeurs de retour, mais il est encore plus simple de consulter la documentation de la bibliothèque.

Vous devriez considérer que les systèmes alternatifs peuvent également être des décisions de conception acceptables.

Coques: 0 l'état de sortie est vrai, non-zéro est faux

L'exemple de shells traitant un statut de sortie 0 comme étant true a déjà été mentionné.

$ ( exit 0 ) && echo "0 is true" || echo "0 is false"
0 is true
$ ( exit 1 ) && echo "1 is true" || echo "1 is false"
1 is false

La raison en est qu'il y a un moyen de réussir, mais de nombreuses façons d'échouer. Par conséquent, utiliser 0 comme valeur spéciale signifiant "pas d'erreur" est pragmatique.

Ruby: 0 est comme n'importe quel autre numéro

Parmi les langages de programmation "normaux", il existe des valeurs aberrantes, telles que Ruby, qui traitent 0 comme une valeur vraie.

$ irb
irb(main):001:0> 0 ? '0 is true' : '0 is false'
=> "0 is true"

Le raisonnement est que seulement falseet nildevrait être faux. Pour beaucoup de novices Ruby, c'est un piège. Cependant, dans certains cas, il est agréable que 0 soit traité comme n'importe quel autre nombre.

irb(main):002:0> (pos = 'axe' =~ /x/) ? "Found x at position #{pos}" : "x not found"
=> "Found x at position 1"
irb(main):003:0> (pos = 'xyz' =~ /x/) ? "Found x at position #{pos}" : "x not found"
=> "Found x at position 0"
irb(main):004:0> (pos = 'abc' =~ /x/) ? "Found x at position #{pos}" : "x not found"
=> "x not found"

Cependant, un tel système ne fonctionne que dans une langue capable de distinguer les booléens d'un type distinct des nombres. Au début de l'informatique, les programmeurs travaillant avec le langage assembleur ou le langage machine brut n'avaient pas ce luxe. Il est probablement naturel de considérer 0 comme l'état "vide" et de définir un bit sur 1 comme indicateur lorsque le code détecte que quelque chose s'est passé. Par extension, la convention élaborée établissait que zéro était traité comme faux et que les valeurs non nulles devenaient vraies. Cependant, il n'est pas nécessaire que ce soit comme ça.

Java: les nombres ne peuvent pas être traités comme des booléens

En Java, trueet falsesont les seules valeurs booléennes. Les nombres ne sont pas des booléens et ne peuvent même pas être convertis en booléens ( spécification du langage Java, section 4.2.2 ):

Il n'y a pas d'incantation entre les types intégraux et le type boolean.

Cette règle évite simplement la question - toutes les expressions booléennes doivent être explicitement écrites dans le code.

Avant d'aborder le cas général, nous pouvons discuter de vos contre-exemples.

Comparaisons de chaînes

La même chose vaut pour beaucoup de sortes de comparaisons, en fait. De telles comparaisons calculent une distance entre deux objets. Lorsque les objets sont égaux, la distance est minimale. Ainsi, lorsque la "comparaison réussit", la valeur est 0. Mais en réalité, la valeur de retour de strcmpn'est pas un booléen, c'est une distance et c'est ce qui piège les programmeurs ignorants if (strcmp(...)) do_when_equal() else do_when_not_equal().

En C ++, nous pourrions reconcevoir strcmppour renvoyer un Distanceobjet, qui se substitue operator bool()à vrai lorsque 0 (mais vous seriez alors piqué par un ensemble de problèmes différent). Ou simplement, C a juste une streqfonction qui retourne 1 quand les chaînes sont égales, et 0 sinon.

Appels API / code de sortie du programme

Ici, vous vous souciez de la raison pour laquelle quelque chose a mal tourné, car cela poussera les décisions vers le haut en erreur. Lorsque les choses réussissent, vous ne voulez rien savoir de particulier, votre intention est réalisée. La valeur de retour doit donc transmettre cette information. Ce n'est pas un booléen, c'est un code d'erreur. La valeur d'erreur spéciale 0 signifie "pas d'erreur". Le reste de la plage représente les erreurs significatives localement que vous devez traiter (y compris 1, ce qui signifie souvent "erreur non spécifiée").

Cas général

Cela nous laisse avec la question: pourquoi les valeurs booléennes Trueet Falsecommunément représentées avec 1 et 0, respectivement?

Eh bien, outre l'argument subjectif "on se sent mieux de cette façon", voici quelques raisons (subjectives aussi) auxquelles je peux penser:

• Analogie avec un circuit électrique. Le courant est activé pour 1s et désactivé pour 0s. J'aime avoir (1, oui, vrai, activé) ensemble et (0, non, faux, désactivé), plutôt qu'un autre mélange

• initialisations de la mémoire. Quand je suis memset(0)un groupe de variables (que ce soit des ints, des floats, des bools), je veux que leur valeur corresponde aux hypothèses les plus conservatrices. Par exemple, ma somme est initialement égale à 0, le prédicat est faux, etc.

Peut-être que toutes ces raisons sont liées à mon éducation - si on m'avait appris à associer 0 à True dès le début, j'aurais choisi l'inverse.

D'un point de vue général, vous parlez de trois types de données très différents:

1. Un booléen. La convention mathématique en algèbre booléenne est d'utiliser 0 pour falseet 1 pour true, il est donc logique de suivre cette convention. Je pense que cette façon de faire est également plus logique intuitivement.

2. Le résultat de la comparaison. Cela a trois valeurs: <, =et >(notez qu'aucun d'entre eux est true). Pour eux, il est judicieux d'utiliser les valeurs -1, 0 et 1, respectivement (ou, plus généralement, une valeur négative, zéro et une valeur positive).

   Si vous voulez vérifier l’égalité et que vous n’avez qu’une fonction qui effectue une comparaison générale, je pense que vous devriez la rendre explicite en utilisant quelque chose comme strcmp(str1, str2) == 0. L'utilisation !de cette situation est source de confusion car elle traite une valeur non booléenne comme s'il s'agissait d'un booléen.

   Aussi, gardez à l'esprit que la comparaison et l'égalité ne doivent pas nécessairement être la même chose. Par exemple, si vous commandez des personnes en fonction de leur date de naissance, elles Compare(me, myTwin)devraient revenir 0, mais Equals(me, myTwin)devraient y revenir false.

3. Le succès ou l'échec d'une fonction, éventuellement avec des détails sur ce succès ou cet échec. Si vous parlez de Windows, ce type est appelé HRESULTet une valeur non nulle n'indique pas nécessairement un échec. En fait, une valeur négative indique un échec et un succès non négatif. La valeur de réussite est très souvent S_OK = 0, mais il peut également s'agir par exemple S_FALSE = 1, ou d'autres valeurs.

La confusion vient du fait que trois types de données logiquement très différents sont représentés sous la forme d’un seul type de données (un entier) en C et dans d’autres langues et que vous pouvez utiliser un entier dans une condition. Mais je ne pense pas qu'il serait logique de redéfinir booléen pour rendre l'utilisation de certains types non booléens dans des conditions plus simples.

En outre, considérons un autre type souvent utilisé dans une condition de C: un pointeur. Là-bas, il est naturel de traiter un NULLpointeur (représenté par 0) comme false. Il serait donc également plus difficile de travailler avec des indicateurs en suivant votre suggestion. (Bien que, personnellement, je préfère explicitement comparer les pointeurs avec NULL, au lieu de les traiter comme des booléens.)

Zéro peut être faux car la plupart des processeurs ont un indicateur ZÉRO qui peut être utilisé pour créer une branche. Il enregistre une opération de comparaison.

Voyons pourquoi.

Certains psuedocode, car le public ne lit probablement pas assemblage

c-source appelle des appels de boucle simples wibble 10 fois

for (int foo =10; foo>0; foo-- ) /* down count loop is shorter */
{  
   wibble();
}

certains prétendent assembler pour cela

0x1000 ld a 0x0a      'foo=10
0x1002 call 0x1234    'call wibble()
0x1005 dec a          'foo--
0x1006 jrnz -0x06      'jump back to 0x1000 if not zero
0x1008  

c- source une autre simple boucle appelle wibble 10 fois

for (int foo =0; foo<10; foo-- ) /* up count loop is longer  */
{  
   wibble();
}

certains prétendent assembler pour ce cas

0x1000 ld a 0x00      'foo=0
0x1002 call 0x1234    'call wibble()
0x1005 dec a          'foo--
0x1006 cmp 0x0a       'compare foo to 10 ( like a subtract but we throw the result away)
0x1008 jrns -0x08      'jump back to 0x1000 if compare was negative
0x100a  

un peu plus c source

int foo=10;
if ( foo ) wibble()

et l'assemblée

0x1000 ld a 0x10
0x1002 jz 0x3
0x1004 call 0x1234
0x1007  

voyez comme c'est court?

un peu plus c source

int foo=10;
if ( foo==0 ) wibble()

et l'assembly (supposons un compilateur marginalement intelligent qui peut remplacer == 0 sans comparaison)

0x1000 ld a 0x10
0x1002 jz 0x3
0x1004 call 0x1234
0x1007  

Essayons maintenant une convention de true = 1

un peu plus c source #define TRUE 1 int foo = TRUE; if (foo == TRUE) wibble ()

et l'assemblée

0x1000 ld a 0x1
0x1002 cmp a 0x01
0x1004 jz 0x3
0x1006 call 0x1234
0x1009 

voyez combien le cas avec true est vrai?

Très tôt, les processeurs avaient de petits ensembles de drapeaux attachés à l'accumulateur.

Pour vérifier si a> b ou a = b prend généralement une instruction de comparaison.

• Sauf si B est égal à ZERO - dans ce cas, l'indicateur ZERO est défini. Implémenté sous forme de NOR logique simple ou tous les bits de l'accumulateur.
• Ou NÉGATIF ​​dans lequel il suffit d'utiliser le "bit de signe", c'est-à-dire le bit le plus significatif de l'accumulateur si vous utilisez l'arithmétique du complément à deux. (Surtout nous le faisons)

Permet de reformuler cela. Sur certains processeurs plus anciens, vous n'avez pas eu à utiliser une instruction de comparaison pour accumulateur égale à ZERO, ou un accumulateur inférieur à zéro.

Maintenant, voyez-vous pourquoi zéro pourrait être faux?

Veuillez noter que ceci est du code pseudo et qu'aucun jeu d'instructions réel ne ressemble à cela. Si vous connaissez l'assemblée, vous savez que je simplifie beaucoup les choses ici. Si vous savez quelque chose sur la conception du compilateur, vous n'avez pas besoin de lire cette réponse. Tous ceux qui connaissent le déroulage en boucle ou la prédiction de branche, la classe avancée se trouve dans la salle 203.

Il y a beaucoup de réponses qui suggèrent qu'une correspondance entre 1 et true est rendue nécessaire par certaines propriétés mathématiques. Je ne peux pas trouver une telle propriété et suggère que c'est une convention purement historique.

Dans un champ à deux éléments, nous avons deux opérations: addition et multiplication. Nous pouvons mapper les opérations booléennes sur ce champ de deux manières:

Traditionnellement, nous identifions Vrai avec 1 et Faux avec 0. Nous identifions AND avec * et XOR avec +. Ainsi, OR est une addition saturante.

Cependant, nous pourrions tout aussi facilement identifier True avec 0 et False avec 1. Ensuite, nous identifions OR avec * et XNOR avec +. Ainsi, AND est une addition saturante.

Étrangement, zéro n'est pas toujours faux.

En particulier, les conventions Unix et Posix définissent EXIT_SUCCESS0 (et EXIT_FAILURE1). En fait, il s’agit même d’une convention C standard !

Donc, pour les shells Posix et les appels système exit (2) , 0 signifie "success", ce qui est intuitivement plus vrai que faux.

En particulier, le shell ifveut qu'un retour de processus EXIT_SUCCESS(c'est-à-dire 0) suive sa branche "then"!

Dans Scheme (mais pas dans Common Lisp ni dans MELT ) 0 et nil (c'est- ()à- dire dans Scheme) sont vrais, puisque la seule valeur fausse est#f

^{Je suis d'accord, je suis nerveux!}

C est utilisé pour la programmation de bas niveau proche du matériel, domaine dans lequel vous devez parfois basculer entre les opérations au niveau du bit et les opérations logiques, sur les mêmes données. Etre obligé de convertir une expression numérique en booléen juste pour effectuer un test encombrerait le code.

Vous pouvez écrire des choses comme:

if (modemctrl & MCTRL_CD) {
   /* carrier detect is on */
}

plutôt que

if ((modemctrl & MCTRL_CD) != 0) {
    /* carrier detect is on */
}

Dans un exemple isolé, ce n’est pas si grave, mais cela sera pénible.

De même, conversez des opérations. Il est utile que le résultat d'une opération booléenne, comme une comparaison, produise simplement un 0 ou un 1: Supposons que nous voulions définir le troisième bit d'un mot en fonction de modemctrll'activation du bit de détection de porteuse:

flags |= ((modemctrl & MCTRL_CD) != 0) << 2;

Ici, nous devons avoir le != 0pour réduire le résultat de l' &expression biwise à 0ou 1, mais comme le résultat n'est qu'un entier, nous évitons d'avoir à ajouter un casting ennuyeux pour convertir davantage booléen en entier.

Bien que le C moderne ait maintenant un booltype, il conserve la validité d'un code comme celui-ci, à la fois parce que c'est une bonne chose et à cause de la rupture massive avec compatibilité ascendante qui serait autrement causée.

Un autre exemple où C est lisse: tester deux conditions booléennes en tant que commutateur à quatre directions:

switch (foo << 1 | bar) {  /* foo and bar booleans are 0 or 1 */
case 0: /* !foo && !bar */
   break;
case 1: /* !foo && bar */
   break;
case 2: /* foo && !bar */
   break;
case 3: /* foo && bar */
   break;
}

Vous ne pouvez pas enlever cela au programmeur C sans vous battre!

Enfin, C sert parfois de langage d'assemblage de haut niveau. Dans les langages d'assemblage, nous n'avons pas non plus de types booléens. Une valeur booléenne est juste un bit ou une valeur zéro par rapport à une valeur différente de zéro dans un emplacement de mémoire ou un registre. Un entier zéro, un booléen zéro et l'adresse zéro sont tous testés de la même manière dans les jeux d'instructions en langage assembleur (et peut-être même à virgule zéro). La ressemblance entre le langage C et le langage assembleur est utile, par exemple lorsque C est utilisé comme langage cible pour la compilation d'un autre langage (même celui qui a des booléens fortement typés!)

Une valeur booléenne ou vérité n'a que 2 valeurs. Vrai et faux.

Ceux-ci ne devraient pas être représentés sous forme d'entiers, mais sous forme de bits (0 et 1).

Dire n'importe quel autre entier à côté de 0 ou 1 n'est pas faux est une déclaration déroutante. Les tables de vérité traitent des valeurs de vérité, pas des entiers.

D'une valeur de vérité prospective, -1 ou 2 briseraient toutes les tables de vérité et toute logique booléenne associée à celles-ci.

• 0 AND -1 ==?!
• 0 OU 2 ==?!

La plupart des langues ont généralement un booleantype qui, lorsqu'il est converti en un type de nombre tel que entier, révèle que false doit être converti en une valeur entière égale à 0.

En fin de compte, vous parlez de casser le langage principal car certaines API sont de mauvaise qualité. Les API Crappy ne sont pas nouvelles et vous ne pouvez pas les réparer en cassant le langage. C’est un fait mathématique que 0 est faux et 1 vrai, et toute langue qui ne le respecte pas est fondamentalement brisée. La comparaison à trois voies est un créneau et il n’ya pas d’affaire qui convertit implicitement son résultat boolcar elle renvoie trois résultats possibles. Les anciennes API C ont simplement une terrible gestion des erreurs et sont également bloquées, car C n’a pas les fonctionnalités de langage nécessaires pour ne pas avoir d’interfaces terribles.

Notez que je ne dis pas cela pour les langues qui n'ont pas de conversion implicite-> booléenne implicite.