Pourquoi recevons-nous un avertissement de référence nulle de déréférence possible, alors que la référence nulle ne semble pas être possible?

Après avoir lu cette question sur HNQ, j'ai continué à lire sur les types de référence Nullable en C # 8 et j'ai fait quelques expériences.

Je suis très conscient que 9 fois sur 10, voire plus souvent, quand quelqu'un dit "J'ai trouvé un bug de compilation!" c'est en fait par conception, et leur propre malentendu. Et depuis que j'ai commencé à étudier cette fonctionnalité seulement aujourd'hui, je ne l'ai clairement pas très bien comprise. Avec cela à l'écart, regardons ce code:

#nullable enable
class Program
{
    static void Main()
    {
        var s = "";
        var b = s == null; // If you comment this line out, the warning on the line below disappears
        var i = s.Length; // warning CS8602: Dereference of a possibly null reference
    }
}

Après avoir lu la documentation que j'ai liée à ci-dessus, je m'attendrais à ce que la s == nullligne me donne un avertissement - après tout, il sest clairement non nul, donc la comparer à nulln'a pas de sens.

Au lieu de cela, je reçois un avertissement sur la ligne suivante , et l'avertissement dit que sc'est possible une référence nulle, même si, pour un humain, il est évident que ce n'est pas le cas.

De plus, l'avertissement ne s'affiche pas si nous ne comparons pas sà null.

J'ai fait quelques recherches sur Google et j'ai rencontré un problème avec GitHub , qui s'est avéré être quelque chose de complètement différent, mais au cours du processus, j'ai eu une conversation avec un contributeur qui a donné un aperçu de ce comportement (par exemple, "les vérifications nulles sont souvent un moyen utile de dire au compilateur de réinitialiser son inférence précédente sur la nullité d'une variable. " ). Cela m'a cependant laissé la question principale sans réponse.

Plutôt que de créer un nouveau problème GitHub, et de prendre potentiellement le temps des contributeurs du projet incroyablement occupés, je mets cela à la disposition de la communauté.

Pourriez-vous m'expliquer ce qui se passe et pourquoi? En particulier, pourquoi aucun avertissement n'est généré sur la s == nullligne, et pourquoi avons-nous CS8602quand il ne semble pas qu'une nullréférence soit possible ici? Si l'inférence de nullité n'est pas à l'épreuve des balles, comme le suggère le thread GitHub lié, comment peut-il mal tourner? Quels seraient quelques exemples de cela?

C'est en fait un doublon de la réponse que @stuartd a liée, donc je ne vais pas entrer dans les détails super profonds ici. Mais la racine du problème est que ce n'est ni un bogue de langue ni un bogue de compilateur, mais c'est un comportement prévu exactement tel qu'implémenté. Nous suivons l'état nul d'une variable. Lorsque vous déclarez initialement la variable, cet état est NotNull car vous l'initialisez explicitement avec une valeur qui n'est pas nulle. Mais nous ne savons pas d'où vient ce NotNull. Ceci, par exemple, est en fait un code équivalent:

#nullable enable
class Program
{
    static void Main()
    {
        M("");
    }
    static void M(string s)
    {
        var b = s == null;
        var i = s.Length; // warning CS8602: Dereference of a possibly null reference
    }
}

Dans les deux cas, vous testez explicitement spour null. Nous prenons cela comme entrée dans l'analyse de flux, tout comme Mads a répondu dans cette question: https://stackoverflow.com/a/59328672/2672518 . Dans cette réponse, le résultat est que vous obtenez un avertissement sur le retour. Dans ce cas, la réponse est que vous obtenez un avertissement que vous avez déréférencé une référence éventuellement nulle.

Il ne devient pas annulable, simplement parce que nous étions assez stupides pour le comparer null.

Oui, en fait. Au compilateur. En tant qu'humains, nous pouvons regarder ce code et évidemment comprendre qu'il ne peut pas lever d'exception de référence nulle. Mais la façon dont l'analyse de flux nullable est implémentée dans le compilateur ne le peut pas. Nous avons discuté d'une certaine quantité d'améliorations à cette analyse où nous ajoutons des états supplémentaires en fonction de la provenance de la valeur, mais nous avons décidé que cela ajoutait beaucoup de complexité à la mise en œuvre pour pas beaucoup de gain, car les seuls endroits où cela serait utile dans des cas comme celui-ci, où l'utilisateur initialise une variable avec une newou une valeur constante, puis la vérifie nullquand même.

Si l'inférence de nullité n'est pas à l'épreuve des balles, [..] comment peut-elle mal tourner?

J'ai volontiers adopté les références annulables de C # 8 dès qu'elles étaient disponibles. Comme j'étais habitué à utiliser la notation [NotNull] (etc.) de ReSharper, j'ai remarqué quelques différences entre les deux.

Le compilateur C # peut être dupe, mais il a tendance à pécher par excès de prudence (généralement, pas toujours).

Comme référence pour les futurs visiteurs, voici les scénarios pour lesquels j'ai vu le compilateur être assez confus (je suppose que tous ces cas sont de par leur conception):

• Null pardonnant null . Souvent utilisé pour éviter l'avertissement de déréférencement, mais en gardant l'objet non nullable. Il semble vouloir garder son pied dans deux chaussures.

    string s = null!; //No warning

• Analyse de surface . Par opposition à ReSharper (qui le fait en utilisant l' annotation de code ), le compilateur C # ne prend toujours pas en charge une gamme complète d'attributs pour gérer les références nullables.

    void DoSomethingWith(string? s)
    {    
        ThrowIfNull(s);
        var split = s.Split(' '); //Dereference warning
    }

Il permet cependant d'utiliser une construction pour vérifier la nullité qui supprime également l'avertissement:

    public static void DoSomethingWith(string? s)
    {
        Debug.Assert(s != null, nameof(s) + " != null");
        var split = s.Split(' ');  //No warning
    }

ou (encore assez cool) des attributs (trouvez-les tous ici ):

    public static bool IsNullOrEmpty([NotNullWhen(false)] string? value)
    {
        ...
    }

• Analyse de code sensible . C'est ce que vous avez mis en lumière. Le compilateur doit faire des hypothèses pour fonctionner et parfois elles peuvent sembler contre-intuitives (pour les humains, au moins).

    void DoSomethingWith(string s)
    {    
        var b = s == null;
        var i = s.Length; // Dereference warning
    }

• Problèmes avec les génériques . Interrogé ici et expliqué très bien ici (même article que précédemment, paragraphe "Le problème avec T?"). Les génériques sont compliqués car ils doivent rendre les références et les valeurs heureuses. La principale différence est que tandis que string?n'est qu'une chaîne, int?devient un Nullable<int>et oblige le compilateur à les gérer de manière sensiblement différente. Ici aussi, le compilateur choisit le chemin d'accès sécurisé, vous forçant à spécifier ce que vous attendez:

    public interface IResult<out T> : IResult
    {
        T? Data { get; } //Warning/Error: A nullable type parameter must be known to be a value type or non-nullable reference type.
    }

Résolu donnant des contraintes:

    public interface IResult<out T> : IResult where T : class { T? Data { get; }}
    public interface IResult<T> : IResult where T : struct { T? Data { get; }}

Mais si nous n'utilisons pas de contraintes et supprimons le "?" à partir de Data, nous pouvons toujours y mettre des valeurs nulles en utilisant le mot-clé 'default':

    [Pure]
    public static Result<T> Failure(string description, T data = default)
        => new Result<T>(ResultOutcome.Failure, data, description); 
        // data here is definitely null. No warning though.

Le dernier me semble le plus délicat, car il permet d'écrire du code dangereux.

J'espère que cela aide quelqu'un.