Super, tu vas pouvoir t'embrouiller entre «None» le lundi, «NULL» le mardi et «null» le vendredi, parce que BIEN SÛR chaque langage devait choisir une convention différente des autres.
Ah mais c'est pas pareil, None et NULL !
(Enfin, surtout le None d'OCaml, parce que le None de Python ressemble un peu à rien et est difficilement utilisable (je trouve, dans mon expérience assez limitée))
Alors je suis d'accord que le None de OCaml (ou le Nothing de Haskell, parce que là aussi ils ne pouvaient pas se mettre d'accord sur un nom…) n'ont pas grand-chose à voir avec le None de Python, mais c'est toi qui as ajouté OCaml dans la discussion, là!
En fait c'est difficile de faire la comparaison parce que Python n'a pas vraiment de typage. L'idée du null du Java c'est que c'est une valeur qui peut servir dans n'importe quelle classe d'objet, et qui représente conventionnellement l'absence de valeur/objet. …
alors… sauf erreur de ma part, en Rust, qui a des types algébriques comme en OCaml, si tu fais option X où X est un type référence (donc non nullable), l'optimisation fait que None est représenté par NULL
ça c'est un choix d'implémentation et peu m'en chaut : un type option avec avertissement du compilateur en cas de non exhaustivité du filtrage, je trouve (en tant qu'utilisateur dont le langage le plus maîtrisé reste probablement encore le C) que c'est *vraiment* différent des pointeurs [...]
Quand je dis "difficilement utilisable", c'est dans le sens "difficile d'en faire quelque chose d'utile", et ça ☝️ est précisément une des raisons pour lesquelles je le pense. Plutôt que d'avoir un type option bien fait (mais bon, les types bien faits en Python...), quand on se récupère un None [...]
[...] on a finalement assez peu d'informations sur ce qui s'est passé
(aussi, un type option sans avertissement en cas de non-exhaustivité de traitement, c'est pas super utile ; en vrai je me demande pourquoi il y a seulement un type None en Python)
Je ne comprends toujours pas que personne n'ait fait un générateur de cheat sheets où on donne une poignée de langages et il écrit un tableau synthétique comparant les trucs évidents entre ces langages (p.ex., est-ce que c'est «else if», «elseif», «elsif» ou «elif» — LE TRUC QUE JE NE SAIS JAMAIS).
Ben pour les langages où c'est «else if», forcément, non, sauf si tu veux dire que je peux essayer tous les autres un par un, mais je ne suis pas sûr de tous les avoir. Et parfois je ne suis pas dans un éditeur de code (genre, je rédige un tweet ou un poly ou je ne sais quoi).
Ah oui, bien sûr, le C++ étant un langage différent du C ils ne pouvaient évidemment pas garder la même convention que le C. 🙄
(Je suis sûr qu'il y a une raison au changement, et sans rien y connaître je peux d'ores et déjà dire qu'elle est complètement pourrie et qu'en vrai c'est du pur NIH. 😛)
Je ne veux vraiment pas savoir pourquoi NULL ne serait pas défini comme “(void *)0” (ou, d'ailleurs, “nullptr” qui convertirait en 0 en contexte entier).
Comments
(Enfin, surtout le None d'OCaml, parce que le None de Python ressemble un peu à rien et est difficilement utilisable (je trouve, dans mon expérience assez limitée))
(aussi, un type option sans avertissement en cas de non-exhaustivité de traitement, c'est pas super utile ; en vrai je me demande pourquoi il y a seulement un type None en Python)
(Je suis sûr qu'il y a une raison au changement, et sans rien y connaître je peux d'ores et déjà dire qu'elle est complètement pourrie et qu'en vrai c'est du pur NIH. 😛)