【C#】null許容参照型（NRT）完全ガイド｜コンテキスト4状態・フロー解析・Nullable属性・ジェネリック対応・段階的移行まで

// NRT 無効（C# 7 以前の動作）
string s = null;       // 代入可能
s.Length;              // 実行時に NullReferenceException

// NRT 有効: string と string? が区別される
string notNull = "x";       // null 不可（警告）
string? canBeNull = null;   // null 可

notNull = null;             // 警告 CS8625
canBeNull.Length;           // 警告 CS8602（null の可能性）

// 重要: 警告を無視してコンパイルしても動く
// ランタイムの挙動は何も変わっていない
// → 実行時に null が入れば従来通り NullReferenceException

// NRT は「開発時に null 漏れを検出する静的解析」である

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <!-- 新規プロジェクトはこれが既定 -->
    <Nullable>enable</Nullable>
    <!-- さらに警告をエラー扱いにしたいとき -->
    <WarningsAsErrors>Nullable</WarningsAsErrors>
  </PropertyGroup>
</Project>

// ファイル全体を enable にする（プロジェクト設定より優先）
#nullable enable

public class A
{
    public string Name { get; set; } = "";  // NRT 有効
}

// 特定のメソッドだけ無効化（レガシーコード統合時）
#nullable disable
public class Legacy
{
    public string Name { get; set; }  // 警告なし
}
#nullable restore   // 以前のコンテキストに戻す

// 警告だけ無効化（アノテーションは有効）
#nullable disable warnings
// ここでは ? の意味は残るが null 関連の警告は出ない
#nullable restore warnings

void Process(string? input)
{
    // 警告: input は null の可能性
    // Console.WriteLine(input.Length);

    // パターン① — != null で狭める
    if (input != null)
        Console.WriteLine(input.Length);   // OK: input は null でない状態

    // パターン② — is not null（C# 9+）
    if (input is not null)
        Console.WriteLine(input.Length);   // OK

    // パターン③ — 早期リターン
    if (input is null) return;
    Console.WriteLine(input.Length);       // OK: この後 input は null ではない

    // パターン④ — string.IsNullOrEmpty（属性で伝える）
    if (string.IsNullOrEmpty(input)) return;
    Console.WriteLine(input.Length);       // OK: IsNullOrEmpty は NotNullWhen(false)

    // パターン⑤ — null 合体で非 null 化
    string safe = input ?? "default";
    Console.WriteLine(safe.Length);        // OK

    // パターン⑥ — throw で契約
    string nonNull = input ?? throw new ArgumentNullException(nameof(input));
    Console.WriteLine(nonNull.Length);     // OK

    // パターン⑦ — null 条件演算子
    int? len = input?.Length;              // null なら null
    Console.WriteLine(len ?? -1);
}

using System.Diagnostics.CodeAnalysis;

// 戻り値が true のとき result は非 null 、false のとき null になり得る
public bool TryGetUser(int id, [NotNullWhen(true)] out User? result)
{
    result = _db.Find(id);
    return result is not null;
}

// 呼び出し側
if (TryGetUser(1, out User? user))
{
    Console.WriteLine(user.Name);  // OK: true だったので user は非 null
}
else
{
    // Console.WriteLine(user.Name); // 警告: user は null の可能性
}

// .NET 標準の string.IsNullOrEmpty もこの属性が付いている
// public static bool IsNullOrEmpty([NotNullWhen(false)] string? value)

using System.Diagnostics.CodeAnalysis;

// input が null なら null を返し、非 null なら非 null を返す
[return: NotNullIfNotNull(nameof(input))]
public string? Trim(string? input) => input?.Trim();

// 呼び出し側
string? a = Trim(null);        // a は null の可能性
string  b = Trim("hello");     // "hello" は非 null なので戻り値も非 null と推論される
// → 呼び出し側の ! が不要になる。ライブラリ設計の定番イディオム

public class Connection
{
    private string? _connStr;

    [MemberNotNull(nameof(_connStr))]
    public void Configure(string host)
    {
        _connStr = $"host={host}";
    }

    public void Use()
    {
        // _connStr が null なら警告
        // Configure 呼び出し後は MemberNotNull で非 null と判明する
    }
}

// コンストラクタで複数フィールドを初期化するとき
public class Service
{
    private string _name;
    private List<string> _tags;

    public Service(string name) => Init(name);

    [MemberNotNull(nameof(_name), nameof(_tags))]
    private void Init(string name)
    {
        _name = name;
        _tags = new();
    }
}
// → コンストラクタで Init を呼ぶだけで _name / _tags が初期化されたとコンパイラが認識

using System.Diagnostics.CodeAnalysis;

public static class Throw
{
    [DoesNotReturn]
    public static void InvalidOperation(string message)
        => throw new InvalidOperationException(message);

    [DoesNotReturn]
    public static T NotFound<T>(string name)
        => throw new KeyNotFoundException($"{name} not found");
}

// 使用側
public string GetName(User? user)
{
    if (user is null) Throw.InvalidOperation("user required");
    return user.Name;   // OK: Throw.InvalidOperation は戻らないので user は非 null
}

// ① T? は T が参照型でも値型でも「null 許容」を表す（C# 9+）
public class Container<T>
{
    public T? Value { get; set; }
}

var intContainer = new Container<int>();       // Value は int?
var strContainer = new Container<string>();    // Value は string?

// ② where T : notnull — null を許さないことを保証する制約
public sealed class NonNullCache<TKey> where TKey : notnull
{
    private readonly Dictionary<TKey, string> _cache = new();
    public void Add(TKey key, string value) => _cache[key] = value;
}

// NonNullCache<string?> とはコンパイルできない（notnull 違反）
// 通常の Dictionary のキー制約もこれ
public sealed class Dictionary<TKey, TValue> where TKey : notnull { }

// ③ where T : class で参照型のみ、where T : class? で nullable 参照型も許可
public class RefOnly<T> where T : class { }    // T は非 null 参照型
public class RefNullable<T> where T : class? { } // T は null 可の参照型

// ④ default(T) の扱いが複雑
public T? GetOrDefault<T>(Dictionary<string, T> dict, string key)
{
    // T がクラスか構造体か不明なので default(T) は警告対象
    return dict.TryGetValue(key, out var v) ? v : default;
    // C# 9+: 戻り値が T? なので default でも警告されない
}

// C# 11 の required と NRT の組み合わせで「必須かつ非 null」を表現
public sealed class User
{
    public required string Name  { get; init; }  // 必須 + 非 null
    public required string Email { get; init; }
    public string? Bio { get; init; }            // 任意 + null 可
}

// NG: Name と Email が必須なので省略できない
// var u = new User();  // CS9035

// OK: 必須プロパティを全部指定
var u = new User { Name = "Alice", Email = "a@x" };

// required がない場合の警告回避テクニック（非推奨）
public sealed class UserOld
{
    public string Name { get; init; } = default!;  // ! で警告抑制
    public string Email { get; init; } = default!;
}
// → ランタイムには null が入るので本質的な解決にならない
// → C# 11+ なら required を使う方が安全

// コンストラクタで初期化するパターン
public sealed class UserCtor
{
    public string Name { get; }

    public UserCtor(string name) => Name = name ?? throw new ArgumentNullException();
}

// 戦略: ファイル単位で徐々に NRT を有効化

// ① プロジェクトは <Nullable>disable</Nullable> のまま
// ② 新規コードのファイルだけ先頭で #nullable enable
// ③ 既存ファイルも優先順位の高いものから enable

// プロジェクト全体 enable + 既存ファイルは disable ディレクティブで逃がす:
// ① <Nullable>enable</Nullable> をプロジェクトに設定
// ② 大量の警告が出る
// ③ 既存ファイル冒頭に #nullable disable を追加 → 警告ゼロ
// ④ ファイルを1つずつ修正して #nullable disable を削除

// モジュール単位での disable
// Services フォルダだけ有効にしたい場合
// Services/*.cs 冒頭に #nullable enable、他は disable

// TreatWarningsAsErrors の段階的適用
<PropertyGroup>
  <Nullable>enable</Nullable>
  <!-- まずは警告として出す -->
  <!-- 移行完了後にエラー化 -->
  <!-- <WarningsAsErrors>Nullable</WarningsAsErrors> -->
  <!-- 特定の警告だけ無効化 -->
  <!-- <NoWarn>CS8618</NoWarn> -->
</PropertyGroup>

using System.Diagnostics.CodeAnalysis;

public static class StringHelper
{
    // ① 入力が null なら null を返し、非 null なら非 null を返す
    [return: NotNullIfNotNull(nameof(input))]
    public static string? Normalize(string? input)
        => input?.Trim().ToLowerInvariant();

    // ② 成功時のみ out が非 null
    public static bool TryParse(string? input, [NotNullWhen(true)] out int? value)
    {
        if (int.TryParse(input, out int v))
        {
            value = v;
            return true;
        }
        value = null;
        return false;
    }

    // ③ 失敗時も null だが戻り値が null 可能
    public static string? SafeGet(Dictionary<string, string> d, string key)
    {
        return d.TryGetValue(key, out var v) ? v : null;
    }

    // ④ 絶対に戻らない例外ヘルパー
    [DoesNotReturn]
    public static T Throw<T>(string message) =>
        throw new InvalidOperationException(message);
}

public void Process(string name)
{
    Console.WriteLine(name.Length);  // NRT 有効でも警告ゼロ
}

// 外部から null が渡ってくるケース
Process(null!);               // ! で抑制すると警告ゼロ
// dynamic d = null; Process(d);        // dynamic → NRT が効かない
// JSON デシリアライズ: JsonSerializer.Deserialize<string>("null");
// → 実行時に NullReferenceException

// 対策: 公開 API の入口ではランタイムチェックを忘れない
public void ProcessSafe(string name)
{
    ArgumentNullException.ThrowIfNull(name);  // .NET 6+
    Console.WriteLine(name.Length);
}

// EF Core: プロパティが非 null だが DB のカラムが NULL 許容だと警告
public sealed class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = "";  // CS8618 回避で ""
    public string? Description { get; set; }  // NULL 許容カラム
}

// JSON: 必須プロパティが JSON から欠けると警告通りにならない
public sealed class ApiResponse
{
    public string Token { get; set; } = "";  // 非 null だが JSON に欠けると ""
}
// System.Text.Json では [JsonRequired] 属性 + NRT + required の組み合わせを使う

// 対策: JSON / DB からのデータは「境界層」で検証し、
//      内部モデルは NRT で null を完全に排除する

// NG: 警告を消すためだけに ! を連打
string? name = GetName();
int len = name!.Length;            // null なら実行時クラッシュ
name!.SendNotificationAsync(...);  // 本質的な null チェックを回避

// OK: ArgumentNullException.ThrowIfNull で明示的に契約
public void UseName(string? name)
{
    ArgumentNullException.ThrowIfNull(name);
    Console.WriteLine(name.Length);  // 以降は非 null と分かる
}

// ! を使うべき限られた場面:
// ① テストの Arrange で「ここは絶対 null ではない」と分かっているとき
// ② NRT 以前の古いライブラリを呼び出して戻り値が絶対 null ではないとき
// ③ [MemberNotNull] 属性を付けられない場面（テストのヘルパー等）

// NRT は参照型のみに影響する
// 値型の nullable は C# 2.0 からある Nullable<T>

int x = 0;        // 従来通り
int? y = null;    // Nullable<int>

// NRT の対象ではないので挙動は変わらない
// ただし「T? がジェネリックで値型にも使える」のは C# 9+
public T? GetOrDefault<T>() { /* ... */ return default; }
// T = int なら T? = int? (Nullable<int>)
// T = string なら T? = string? (NRT)