Retour sur une proposition pour C# 8 : les références nullables
Quels sont les avantages de cette fonctionnalité ?

Le , par François DORIN, Responsable .NET & Magazine
L'erreur à un milliard de dollars
Connaissez-vous Tony Hoare ? Il y a de grandes chances que non. Pourtant, en tant que développeurs, vous utilisez très certainement le fruit de ses travaux. L'un d'entre eux, qu'il qualifie lui-même comme "l'erreur à 1 milliard de dollars", est le pointeur nul, objet du billet d'aujourd'hui.

Très pratique, le pointeur nul est présent dans de nombreux langages. C++, Java, C# pour ne prendre que les exemples de langages les plus répandus.

Par exemple, en C#, la valeur nulle est la valeur par défaut des types références. Si vous allouez un tableau d'objets, chaque case du tableau est initialisée… à nulle ! Ou encore, lorsqu'on souhaite préciser qu'une variable n'a pas de valeur, on l'initialise là aussi à nulle.

Mais qui n'a jamais eu à souffrir, durant l'exécution de son code, d'un NullPointerException ? Que le développeur à qui cela n'est jamais arrivé lève la main ! Cette erreur est fréquente (sans doute l'erreur la plus répandue !) et indique l'absence de valeur là où on en attend une. Cela oblige donc à tester la valeur de la variable avant de l'utiliser.

Et c'est là que réside le problème de la plupart des langages ayant cette notion. Il n'y a rien pour distinguer une valeur nulle fortuite d'une valeur nulle voulue.

Évolution du langage C#
Le lien avec C#8 ? Il y a actuellement de longues discussions autour d'une fonctionnalité portant le nom de "référence nullable"(nullable reference dans la langue de Shakespeare), qui permettrait justement de préciser si une référence peut être nulle ou non.

Si on passe outre l'aspect rupture du langage, quels seraient les avantages d'une telle approche ? Et bien le principal avantage est de permettre de corriger de nombreux bogues à la compilation, et non plus à l'exécution.

Ainsi, un code comme
Code c# : Sélectionner tout
1
2
3
4
if (hello.Length == 0) 
{}

Générera une erreur si hello est une variable de type String?, mais pas d'erreur si elle est de type String.

Pour un type String?, il faudra vérifier que la référence est non nulle
Code c# : Sélectionner tout
1
2
3
4
if (hello != null && hello.Length == 0) 
{}

En théorie, c'est très intéressant, mais cela soulève encore de nombreux problèmes, dont toutes les questions n'ont pas encore trouvé réponse. Par exemple, que se passe-t-il si une méthode teste le caractère nul d'une variable ? Par exemple :
Code c# : Sélectionner tout
1
2
3
4
5
String? Hello = "world"; 
if (!String.IsNullOrEmpty(hello)) 
{ 
   int taille = hello.Length; // Générera une erreur ! 
}
Pourquoi une erreur ? Nous, en tant que développeurs, nous savons que la méthode String.IsNullOrEmpty teste le caractère nul ou vide d'une chaîne de caractères. Mais le compilateur ne le sait pas lui. Pour résoudre ce problème, deux approches sont envisageables :
  1. La première, rajouter un test de nullité dans la conditionnelle. Pas terrible. En plus d'être redondant, cela alourdit le code ;
  2. La seconde, introduire une nouvelle syntaxe, permettant de dire au compilateur "OK, je sais ce que je fais, ne génère pas d'erreur" (par exemple, int taille = hello.Length!;).


Des zones d'ombre...
De plus, si cette approche permettrait de résoudre certains problèmes, elle n'est pas sans en poser d'autres, qu'il va aussi falloir résoudre avant de pouvoir déployer cette fonctionnalité :
  • une valeur (notamment une propriété) peut très bien devenir nulle entre le moment où elle a été testée et où la valeur est effectivement utilisée ;
  • des méthodes qui retournent des valeurs non nulles pourront malgré tout retourner des valeurs nulles (cas d'une API qui n'aurait pas été mise à jour par exemple).


Une évolution ou une révolution ?
Le plus gros problème de cette approche reste qu'elle implique une évolution même du langage, évolution "cassante" changeant la sémantique de tout code écrit jusqu'à aujourd'hui. On comprend donc les longues discussions qu'il peut y avoir à ce sujet.

Illustrons ceci avec quelques exemples. Aujourd'hui, ce code est tout à fait valide :
Code c# : Sélectionner tout
1
2
String hello = "World"; 
Hello = null;

Demain, ce code ne sera plus valide, et générera une erreur au niveau de la seconde ligne, lors de l'affectation de la valeur null.

Autrement dit, par défaut, les références ne seront plus nullables. Pour retrouver le comportement actuel, il faudra déclarer les variables comme étant nullables :
Code c# : Sélectionner tout
1
2
String? hello = "World"; 
Hello = null; // Opération valide, puisque hello est nullable.

Pour éviter de casser tout le code existant, ce changement ne générera que des avertissements, et non des erreurs. Mais un code propre d'aujourd'hui pourra se retrouver avec des milliers d'avertissements demain !

Affaire à suivre
Les discussions sont loin d'être terminées. On parle déjà de C#8 alors que la prochaine version attendue de C# est la 7.3. Mais ce changement est loin d'être anodin et il est donc nécessaire de l'anticiper largement en amont, car s'il venait à être adopté, cela sera un changement majeur du langage comme jamais il n'en a connu jusqu'à aujourd'hui.

Sources
le projet C# sur github
exemple de discussion sur Reddit (213 commentaires au moment de l'écriture de ce billet, ce qui est énorme !)


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster un commentaire

Avatar de Madmac Madmac - Membre éclairé https://www.developpez.com
le 27/03/2018 à 1:30
Mais qui n'a jamais eu à souffrir, durant l'exécution de son code, d'un NullPointerException ? Que le développeur à qui cela n'est jamais arrivé lève la main ! Cette erreur est fréquente (sans doute l'erreur la plus répandue !) et indique l'absence de valeur là où on en attend une. Cela oblige donc à tester la valeur de la variable avant de l'utiliser.
Seul les programmeurs qui n'ont jamais eu a vivre avec l'alternative s'en plaignent. Les premières version de pascal n'assignait pas de valeur automatiquement. Avec résultat que les pointeurs pointaient des adresses d'une façon aléatoire. Et dans ce cas de figure, il n'y avait aucun test qui permettait de déterminer si la valeur pointée en était véritablement une. Donc forcément, les programmeurs devaient s'inventer un type NULL d'une façon non conventionnelle. Essayer de faire des fonctions pour des listes chaînées sans null, vous allez vous amuser.


Pour un type String?, il faudra vérifier que la référence est non nulle
Code c# : Sélectionner tout - Visualiser dans une fenêtre à part

Code : Sélectionner tout
1
2
3
if (hello != null && hello.Length == 0)
{
   …
}
C'est un problème uniquement si le programmeur est trop paresseux pour assigne la valeur "" à ses chaînes de caractère au moment de la construction. L'avantage de déclarer dynamiquement ses variable est que le programmeur ne peut utiliser classe Nul à tort et à travers. Le problème vient plutôt de la nature du Null. Si Null est une classe, il toujours identifiable en tant qu'objet. Et vous ne pouvez pas l'assigner à une variable d'une autre classe, à moins que cette classe ait la classe Null comme ancêtre.
Avatar de codec_abc codec_abc - Membre averti https://www.developpez.com
le 27/03/2018 à 9:33
Citation Envoyé par Madmac Voir le message
Seul les programmeurs qui n'ont jamais eu a vivre avec l'alternative s'en plaignent. [,..]
Faux (et la suite du message aussi). Le problème de null/nil dans les langages c'est que c'est un trou dans le système de type. Quand une fonction retourne une string on s'attend a un avoir une string valide et pas un objet manquant. Du coup, la vrai solution est d'utiliser les "sum types" ou les génériques pour modéliser l'absence possible de valeur. Haskell/OCaml/F#/Rust/Swift (entre autres) ont depuis toujours géré les valeurs manquantes de cette façon et ont pu bannir les erreurs de ce type depuis le début.

PS: Une liste chainée en Haskell en 1 ligne de code sans possibilité d'accéder à des éléments qui n'existe pas:

Code : Sélectionner tout
1
2
data MyList a = Cons a (MyList a) | MyNil
Avatar de François DORIN François DORIN - Responsable .NET & Magazine https://www.developpez.com
le 28/03/2018 à 8:16
@Madmac

Le problème n'est pas tant d'avoir une valeur nulle, mais la gestion de cette valeur dans de nombreux langages, où le nul fait parti intégrante des valeurs possibles par défaut. En C# ou en Java par exemple, si une méthode retourne une instance de MaClasse, on ne peut pas savoir si cette valeur sera une véritable instance ou si elle sera nulle. Ainsi, si on appelle une méthode instance.IsEmpty() par exemple, on ne saura pas, sans tester caractère nul, si cette méthode s'exécutera normalement ou si elle générera une exception.

A contrario, si on créé une instance statique de la classe (votre proposition), par exemple MaClasse.Null, alors on peut l'utiliser en tant que valeur nulle. Cela permet d'appeler instance.IsEmpty() sur cette valeur et cela ne générera pas d'erreur (si on admet que cette méthode renvoie true pour une valeur nulle). Pour les opérations "invalides" (par exemple, de modification pour une instance représentant la valeur nulle), on peut générer une exception (par exemple, InvalidArgumentException en C#).

Mais ce n'est pas forcément idéal, car elle oblige à traiter une instance précise de manière particulière dans le code de la classe MaClasse.

Comme le dit @codec_abc, c'est un trou dans le typage, que cette évolution de C# vise à combler, en s'inspirant notamment de ce qui se fait dans les langages fonctionnels. Mais le C# étant par nature un langage procédural, cela ne va pas sans poser de problèmes, comme expliqué dans le billet.
Avatar de jpouly jpouly - Membre actif https://www.developpez.com
le 29/03/2018 à 0:43
Je ne comprend pas ce problème de Null Reference Exception. j'ai beau le tourner dans tous les sens, je ne comprend pas pourquoi c'est une nécessite.

Les tests, unitaires ou fonctionnelles, devraient éviter ce genre d'erreurs, non ? Et l'informatique, c'est déterministe non ?

Et le choix d'un exemple avec une chaine de caractère je ne le comprend pas non plus. Et le caractère null n'existe pas en .NET, c'est pas du C .
Et la classe String est un peu particulière, puisque c'est un type immuable (Lecture seul). Je crois que c'est la seule dans le Framework.

De plus, une des dernière nouveauté de Visual Studio 2015, c'est l'opérateur .? On peut écrire le code suivant :
Code : Sélectionner tout
1
2
if ( hello?.Length ?? 0 == 0)
Ou utiliser la méthode String.IsNullOrEmpty qui fonctionne très bien avec : String hello = null; (sans le ?).

Enfin, pour répondre :
Citation Envoyé par François DORIN Voir le message
@Madmac
Le problème n'est pas tant d'avoir une valeur nulle, mais la gestion de cette valeur dans de nombreux langages, où le nul fait parti intégrante des valeurs possibles par défaut. En C# ou en Java par exemple, si une méthode retourne une instance de MaClasse, on ne peut pas savoir si cette valeur sera une véritable instance ou si elle sera nulle. Ainsi, si on appelle une méthode instance.IsEmpty() par exemple, on ne saura pas, sans tester caractère nul, si cette méthode s'exécutera normalement ou si elle générera une exception.
C'est pour cela que les nouveaux opérateurs .? et ? sont utiles

Citation Envoyé par François DORIN Voir le message

A contrario, si on créé une instance statique de la classe (votre proposition), par exemple MaClasse.Null, alors on peut l'utiliser en tant que valeur nulle. Cela permet d'appeler instance.IsEmpty() sur cette valeur et cela ne générera pas d'erreur (si on admet que cette méthode renvoie true pour une valeur nulle). Pour les opérations "invalides" (par exemple, de modification pour une instance représentant la valeur nulle), on peut générer une exception (par exemple, InvalidArgumentException en C#).
Mais ce n'est pas forcément idéal, car elle oblige à traiter une instance précise de manière particulière dans le code de la classe MaClasse.
Je ne comprend toujours pas le problème. La valeur nulle est un cas possible, qu'il faut tester. Sinon il y a une levée d'exception. C'est la philosophie des langages .NET et de Java.
De plus, les instances statiques, ça s'appelle des singletons. Et ça va à l'encontre, l'a encore, de la philosophie du .NET et du ramasse miette.

Citation Envoyé par François DORIN Voir le message

Comme le dit @codec_abc, c'est un trou dans le typage, que cette évolution de C# vise à combler, en s'inspirant notamment de ce qui se fait dans les langages fonctionnels. Mais le C# étant par nature un langage procédural, cela ne va pas sans poser de problèmes, comme expliqué dans le billet.
C'est bien ce que je crains. A force de vouloir faire de la nouveauté, on fini par faire n'importe quoi.
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 29/03/2018 à 1:11
Hello,

Citation Envoyé par François DORIN;bt7663
A contrario, si on créé une instance statique de la classe (votre proposition), par exemple MaClasse.Null, alors on peut l'utiliser en tant que valeur nulle. Cela permet d'appeler instance.IsEmpty() sur cette valeur et cela ne générera pas d'erreur (si on admet que cette méthode renvoie true pour une valeur nulle). Pour les opérations "invalides" (par exemple, de modification pour une instance représentant la valeur nulle), on peut générer une exception (par exemple, InvalidArgumentException en C#).

Je comprends pas l'intérêt : pour moi on a juste remplacé une syntaxe par une autre, à savoir if (x != null) / NullPointerException par if (!x.IsEmpty()) / InvalidArgumentException.

Je suis perplexe aussi sur l'histoire du trou dans le système de type qui relève selon moi plutôt d'une spécificité à Java / C# dans la mesure où il n'y a pas distinction syntaxique entre le pointeur et l'objet pointé (déréférencement explicite). Mais avec un langage qui distingue clairement le pointeur de sa valeur pointée, null ne vient pas polluer les valeurs possibles pour le type pointé.

C'est inhérent à l'utilisation abusive de new et par conséquent au peu de place accordé à la sémantique de valeur. Car quand il est possible de renvoyer une instance de classe par valeur comme on le fait avec un int, alors le problème disparaît car le pointeur a disparu - et donc null aussi.

Et alors le type pointeur peut même être utilisé pour exprimer le caractère optionnel d'une variable, selon une sémantique très proche d'un type optional / maybe. Typiquement en C/C++, pour exprimer le caractère optionnel d'un argument d'input: void f(int p1, int * p2 = NULL);

Mais c'est clair que pour les types de retour, une abstraction à la optional / maybe est beaucoup plus sympa et robuste!
Avatar de François DORIN François DORIN - Responsable .NET & Magazine https://www.developpez.com
le 29/03/2018 à 8:43
Citation Envoyé par jpouly
Je ne comprend pas ce problème de Null Reference Exception. j'ai beau le tourner dans tous les sens, je ne comprend pas pourquoi c'est une nécessite.

Les tests, unitaires ou fonctionnelles, devraient éviter ce genre d'erreurs, non ? Et l'informatique, c'est déterministe non ?

L'objectif est d'avoir le maximum d'erreur dès la compilation. Les tests, c'est bien, mais :
  • il faut qu'ils soient écrits ;
  • il faut qu'ils soient complets du point de vue de la couverture de code ;
  • il faut qu'ils soient complets du point de vue des jeux de valeurs utilisés ;
  • il faut qu'ils soient maintenu en cas de mise à jour ;
  • il faut qu'ils soient juste.


Citation Envoyé par jpouly
Et le choix d'un exemple avec une chaine de caractère je ne le comprend pas non plus. Et le caractère null n'existe pas en .NET, c'est pas du C .

J'aurais pu prendre une autre classe que la classe String, cela n'aurait pas changé grand chose.

Au sujet du caractère nul, c'est une incompréhension. Mais j'admet que ma tournure de phrase peut semer le trouble Quand je dis "Par exemple, que se passe-t-il si une méthode teste le caractère nul d'une variable ?", le caractère nul n'est pas à prendre comme le caractère 0, mais la valeur de la variable. J'aurais du dire "que se passe-t-il si une méthode teste la nullité d'une variable ?". C'est d'ailleurs ce que j'avais écrit initialement, mais je trouvais ça moche Mais peut être moins "confusant".

Citation Envoyé par jpouly
De plus, une des dernière nouveauté de Visual Studio 2015, c'est l'opérateur .? On peut écrire le code suivant :

Code C# : Sélectionner tout
if ( hello?.Length ?? 0 == 0)

Bobo les yeux Il faut rajouter au minimum un jeu de parenthèses.
Tout d'abord, ça n'a rien à voir avec Visual Studio, mais avec C#. L'opérateur .? a été introduit avec C#6.

Ensuite, si la variable hello n'est pas censée être nulle, dans votre code, vous en traduisez pourtant la possibilité.

Citation Envoyé par jpouly
Je ne comprend toujours pas le problème. La valeur nulle est un cas possible, qu'il faut tester. Sinon il y a une levée d'exception. C'est la philosophie des langages .NET et de Java.

Comme dis plus haut, le problème c'est détection à l'exécution vs détection à la compilation.

Citation Envoyé par jpouly
De plus, les instances statiques, ça s'appelle des singletons. Et ça va à l'encontre, l'a encore, de la philosophie du .NET et du ramasse miette.

Les instances statiques n'ont rien à voir avec le singleton dans le cas présent. D'ailleurs, en cas de singleton, il est inutile d'avoir une instance pour représenter la valeur nulle
Je vous invite sérieusement à revoir la définition d'un singleton de manière approfondie. Un singleton est une classe dont il existe une seule et unique instance. Avoir une instance représentant la valeur nulle n'a donc aucun sens ici !

En ce qui concerne le fait que cela va à l'encontre de la philosophie de .NET et du ramasse-miette, j'attends plus d'information. A commencer par une définition officielle (donc émanant de Microsoft) de cette philosophie. A défaut, votre affirmation est sans aucun fondement. (et ne cherchez pas, c'est le cas).

Citation Envoyé par Aurelien.Regat-Barrel
Je comprends pas l'intérêt : pour moi on a juste remplacé une syntaxe par une autre, à savoir if (x != null) / NullPointerException par if (!x.IsEmpty()) / InvalidArgumentException.

D'une par, c'est une question de sémantique. Avec un NullPointerException, vous n'avez aucune information, si ce n'est qu'il y a un bug. Avec un InvalidArgumentException, vous savez déjà qu'il y a une opération non valide due à un argument invalide. Cela oriente déjà là recherche de bug.

D'autre part, car la valeur nulle est une valeur particulière. Mais que dire s'il y a d'autres valeurs qui sont invalides ? Pourquoi ne pas générer la même exception ? Si vous faite un mécanisme d'authentification par exemple, vous devez avoir un mot de passe. Si le mot de passe est null, ou vide, vous pouvez déclencher la même exception, en précisant l'erreur porte sur le mot de passe. Si on laisse le NullPointerException, vous faite une distinction qui n'a pas lieu d'être.

Citation Envoyé par Aurelien.Regat-Barrel
Je suis perplexe aussi sur l'histoire du trou dans le système de type qui relève selon moi plutôt d'une spécificité à Java / C# dans la mesure où il n'y a pas distinction syntaxique entre le pointeur et l'objet pointé (déréférencement explicite). Mais avec un langage qui distingue clairement le pointeur de sa valeur pointée, null ne vient pas polluer les valeurs possibles pour le type pointé.

Bingo ! C'est justement l'erreur à un milliard de dollars

L'erreur consiste à gérer la valeur nulle de manière implicite. De nombreux problèmes seraient résolus ou évités en ayant une gestion explicite.
Avatar de codec_abc codec_abc - Membre averti https://www.developpez.com
le 29/03/2018 à 9:59
Citation Envoyé par jpouly Voir le message
C'est bien ce que je crains. A force de vouloir faire de la nouveauté, on fini par faire n'importe quoi.
C'est vachement prétentieux de sortir un truc pareil vu les personnes qui bossent sur l'évolution du langage d'autant plus qu'il apparait clairement que tu ne comprends pas vraiment le problème ni les enjeux. Ceci dit cela ne me choque pas vraiment car bossant quasiment uniquement en C# la moitié de mes collègues mélangent les notions de typage statique fort/faible statique/dynamique et l'inférence de type. C'est un peu triste j'ai l'impression que c'est aspect est complétement ignoré lors des formations diplômantes.
Avatar de jpouly jpouly - Membre actif https://www.developpez.com
le 29/03/2018 à 17:35
Citation Envoyé par François DORIN Voir le message
Les tests, c'est bien, mais :
  • il faut qu'ils soient écrits ;
  • il faut qu'ils soient complets du point de vue de la couverture de code ;
  • il faut qu'ils soient complets du point de vue des jeux de valeurs utilisés ;
  • il faut qu'ils soient maintenu en cas de mise à jour ;
  • il faut qu'ils soient juste.

C'est bien le problème des tests, surtout quand ils sont automatisés. Mais cela n’empêche pas de les faire .

Citation Envoyé par François DORIN Voir le message

Bobo les yeux Il faut rajouter au minimum un jeu de parenthèses.
Tout d'abord, ça n'a rien à voir avec Visual Studio, mais avec C#. L'opérateur .? a été introduit avec C#6.
C'est effectivement une évolution du C#6.

Citation Envoyé par François DORIN Voir le message

Ensuite, si la variable hello n'est pas censée être nulle, dans votre code, vous en traduisez pourtant la possibilité.
C'est bien ça le truc, il ne faut jamais considérer qu'une chose est acquise. ça évite les bugs

Citation Envoyé par François DORIN Voir le message

Les instances statiques n'ont rien à voir avec le singleton dans le cas présent. D'ailleurs, en cas de singleton, il est inutile d'avoir une instance pour représenter la valeur nulle
Je vous invite sérieusement à revoir la définition d'un singleton de manière approfondie. Un singleton est une classe dont il existe une seule et unique instance. Avoir une instance représentant la valeur nulle n'a donc aucun sens ici !
En .net, un membre statique d'une classe est accessible par toutes les instances de cette classe. Voir par tout le monde si il est publique. Si c'est pas un singleton, faut admettre qu'il y a un cousinage

Citation Envoyé par François DORIN Voir le message

En ce qui concerne le fait que cela va à l'encontre de la philosophie de .NET et du ramasse-miette, j'attends plus d'information. A commencer par une définition officielle (donc émanant de Microsoft) de cette philosophie. A défaut, votre affirmation est sans aucun fondement. (et ne cherchez pas, c'est le cas).
Il y a bien la présentation du C# (https://docs.microsoft.com/fr-fr/dotnet/csharp/tour-of-csharp/), mais je sens que ça ne va pas vous aller.
Avatar de François DORIN François DORIN - Responsable .NET & Magazine https://www.developpez.com
le 29/03/2018 à 18:16
Citation Envoyé par jpouly Voir le message
En .net, un membre statique d'une classe est accessible par toutes les instances de cette classe. Voir par tout le monde si il est publique. Si c'est pas un singleton, faut admettre qu'il y a un cousinage
Pas du tout. Ce sont bien deux choses différentes. Ce n'est pas parce que l'un (singleton) utilise l'autre (attribut statique de classe) qu'ils sont cousins. Ils ont deux finalités radicalement différentes.

Citation Envoyé par jpouly Voir le message
Il y a bien la présentation du C# (https://docs.microsoft.com/fr-fr/dotnet/csharp/tour-of-csharp/), mais je sens que ça ne va pas vous aller.
Effectivement, cela ne me convient pas. C'est pas que je sois borné (bon, si ça m'arrive), mais cela est bien insuffisant pour plusieurs raisons :
  • dans votre message initial, vous parlez de la philosophie .NET. Là, vous ne me sortez qu'un lien sur le C#. C'est bien méconnaître l'environnement .NET que de le réduire au C#. Il y a par exemple F#, qui lui justement n'a pas tout ces soucis avec la valeur nulle ;
  • c'est une présentation succincte du langage. Cela ne représente en rien la philosophie derrière ce langage ;
  • où est passée la "philosophie" du ramasse-miette ?


En vous lisant, j'ai constaté que vous n'aviez qu'une connaissance superficielle et une compréhension erronée de ce qu'est le C#, la plateforme .NET ou encore le ramasse-miettes. C'est pas un reproche, on ne peut pas tout savoir, et avant de savoir, on est soi-même ignorant. Je vous invite à lire CLR via C#, c'est un excellent ouvrage, très complet, dans lequel vous apprendrez énormément de chose sur tout cela.
Avatar de wadison wadison - Membre à l'essai https://www.developpez.com
le 29/03/2018 à 18:21
Pour une liste vide, 99% des développeurs instancient une liste, et ne laisse pas l'objet à null!!
Avec cette exemple très commun il est assez simple de comprendre l’intérêt de annihiler le null pour toutes les variables de son code! Mais il y a un blocage pour beaucoup, mais je ne comprend pas l’entêtement vue qu'il le font déjà pour des listes. "C'est ADN du langage limite un changement de paradigme"... Je pense que c'est très exagéré comme réaction.

Que le langage l'impose est une très bonne chose, car actuellement nous sommes obligé de rester parano et tester null partout dans le code même si on décide de ne pas affecter de null dans son code.

Deux clans se forment assez vite, c'est un sujet hyper passionné mais je suis content de ne plus être du coté obscur de la force , je me sens moins seul.

l'idée n'est pas de remplacer null avec une variable representant "null" mais plutot instancier avec un objet le plus possible neutre.

exemple 1 :
En lieu et place (dans sa version courte ):
monobject?.monchamp ?? "pas de valeur" autant faire un objet neutre avec monobject.monchamp = "pas de valeur"
exemple 2 : pour les calculs mathématique, il faut utiliser le 1 pour les multiplication pour une addition le 0, etc...

=> dans de très rare cas avoir l'information que l'objet manipulé est "le" neutre est utile.

Rien à voir...
Une feature du langage C# que j’attends c'est la protection des méthodes mutable. Autrement dit pouvoir passer une variable en "lecture seule" qui interdit les appels de méthodes "mutable". Ceci permet une forte encapsulation sans faire de "clone()" dans les getter ou encore mettre en place des Interfaces "readonly".
Ca existe sous C++ nativement.
Contacter le responsable de la rubrique Accueil