Programming w/ C# ～ 抽象 record データコンテナ・テンプレートから派生クラスを Reflection.Emit で動的生成

抽象 record データコンテナ・テンプレートから派生クラスを Reflection.Emit で動的生成

やりたいこと

下記のようなコードがある。

public abstract record Format {
  // EntityFrameworkCore で利用する共通機能を書く
  // プロパティは書かない
}

// データコンテナ・テンプレート (例えばこのようなもの. 実際は業務データのフォーマット.)
[PrimaryKey(nameof(id))]
public abstract record BaseFormat : Format {
  public int    id   { get; init; }
  public string text { get; init; }
}

ここから、下記のようなコードを Reflection.Emit で動的に生成したい。

[Table("table_derived202308", Schema = "oltp")]
public record DerivedFormat202308 : BaseFormat {
}

EntityFrameworkCore を ORM として用いてデータベース接続するのだが、Code First でも Model First でも EntityFrameworkCore を OLAP 目的で使うには２点難点がある。

• 複雑な集合演算が苦手
• テーブル (に紐づけるデータコンテナの型) を動的に作成できない

まあ、１点目は仕方ない。EntityFrameworkCore はメモリと DB 間の激しい相互作用に耐える ORM として設計されていて、テーブル構成をオブジェクト構成に見立てる方向 (Repository Pattern ORM) を目標としている *1 から。すべてを DB サーバーサイドで演算する業務・分析系はクエリビルダを使えということなのだろう。それはそれで不満 *2*3 があって、解消するために自分なりのソリューションを構築したが、それはまた別途紹介する。

ここでの問題は２点目。コード (データコンテナの型) を静的に書かなければならない？ いやいや、OLAP のビッグデータとか 1 テーブルでは済まないから、分割統治するためにパラメータ与えて複数のテーブルをシステマティックに作成したいですけど？ 年間 n 億レコードの会計データなんか溜め込むとしたら、期間分割して年月でテーブル分けしたいと思うのは当然。この CREATE TABLE を人手なんかでは書けませんって。テーブル数も多いし、１つ１つのテーブルだって単純構造ではなく、多段階テーブル・パーティショニングした上で末端テーブルにインデックス付けたりするから SQL は長くなる。これは自動化案件。

要するに EntityFrameworkCore で Model First 的にデータコンテナの型を起点に (でも実際は .ExecuteSqlRaw("CREATE TABLE ...") で) OLAP データキューブ・テーブルを動的に作りたいぞーということ。

というわけで、Reflection.Emit で動的に派生クラス作ってみるぞー。

難所

新しい型を作るには Reflection.Emit を使う。Reflection.Emit は .NET VM の中間コードを組み立てるもの。これがまあ参考情報がなくて難しい。SharpLab などを使って IL ダンプしてみるけど詳しくはわからない (から Chat GPT に解釈させる)。
record class は難しい。なぜなら、プログラマがコードを書かなくても基本機能を C# コンパイラがコード自動生成するものだから。要はコンパイラがやるコード補完を (部分的に) 再現するということ。
継承が難しい。派生クラスから自クラスや基底クラスのコンストラクタやクローンメソッドをどうコールしているか (よく見えないオートマトンを) よく洞察・想像しないと再現できない。
Chat GPT の扱いが難しい。Chat GPT はコード書きは速いが、世間であまり手掛けられていないこなれていない領域に対する知恵はほとんど持ち合わせていない。

試行錯誤すること丸 3 日。Chat GPT にコード書きさせること 20 数回。こちらが期待していることを Chat GPT が汲んでくれなくて堂々巡りすること 5 巡。こちらが知恵を絞り、手を変え品を変え、いろんな角度からちょっとずつヒントを与えて、ほんの少しだけ正解に近づいたかなと思える部分・部分をこそぎ取ってこちらで組み合わせて捏ねていく作品作り ...

結果

結果できたのがコレ。

using System;
using System.ComponentModel.DataAnnotations.Schema;
using System.Reflection;
using System.Reflection.Emit;
using System.Runtime.CompilerServices;

public static class DynamicFormatCreator {
  // static property ***************************************************************************************************

  private static string AssemblyName { get; } = "Assembly";
  private static string ModuleName   { get; } = nameof(DynamicFormatCreator);
  private static string NameSpace    { get => typeof(DynamicFormatCreator).Namespace is {} ns ? $"{ns}." : string.Empty; }

  // static method *****************************************************************************************************

  // 基底 (抽象) クラスである Format のテンプレートから具体クラスを動的に生成する
  // 下記が生成される
  //
  //   [Table($tableName$, Schema = $schemaName$])]
  //   public class $formatTypeName$ : TBaseFormat {}
  public static Type CreateFormat<TBaseFormat>(string derivedTypeName, string tableName, string schemaName) where TBaseFormat : Format {
    var assemblyBuilder    = AssemblyBuilder.DefineDynamicAssembly(new AssemblyName(AssemblyName), AssemblyBuilderAccess.Run);
    var moduleBuilder      = assemblyBuilder.DefineDynamicModule(ModuleName);
    var baseType           = typeof(TBaseFormat);
    var derivedTypeBuilder = moduleBuilder
      .DefineType(derivedTypeName, TypeAttributes.Public, baseType)
      .SetTableAttribute(tableName, schemaName);

    // 派生クラスのコンストラクタを作成する
    baseType.DefineCtor(derivedTypeBuilder, isSelfRef: true ).As(out var derivedCtorBuilder); // 自己参照型コンストラクタ new TDerived(TBase that)
    baseType.DefineCtor(derivedTypeBuilder, isSelfRef: false);                                // デフォルトコンストラクタ new TDerived()

    // 派生クラスの <Clone>$ メソッドを作成する
    baseType.DefineCloneMethod(derivedTypeBuilder, derivedCtorBuilder);

    return derivedTypeBuilder.CreateType();
  }

  // 派生クラスのコンストラクタビルダーを作成し、基底クラスのコンストラクタを呼び出す IL コードを生成する
  private static ConstructorBuilder DefineCtor(this Type baseType, TypeBuilder derivedTypeBuilder, bool isSelfRef) {
    var baseCtorArg    = isSelfRef ? new Type[] { baseType           } : Type.EmptyTypes;
    var derivedCtorArg = isSelfRef ? new Type[] { derivedTypeBuilder } : null           ;
    var ctorBuilder    = derivedTypeBuilder.DefineConstructor(MethodAttributes.Public, CallingConventions.Standard, derivedCtorArg);
    var il             = ctorBuilder.GetILGenerator();
    var baseCtor       = baseType
      .GetConstructor(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance, null, baseCtorArg, null)
      ?? throw new NotImplementedException($"Constructor .ctor({(isSelfRef ? baseType.Name : string.Empty)}) on {baseType.Name} was not found.");

    il.Emit(OpCodes.Ldarg_0);

    if (isSelfRef)
      il.Emit(OpCodes.Ldarg_1);

    il.Emit(OpCodes.Call, baseCtor);
    il.Emit(OpCodes.Ret);

    return ctorBuilder;
  }

  // 派生クラスのメソッドビルダーを作成し、派生クラスのコンストラクタを呼び出す IL コードを生成する
  private static MethodBuilder DefineCloneMethod(this Type baseType, TypeBuilder derivedTypeBuilder, ConstructorBuilder derivedCtorBuilder) {
    var cloneMethodName    = "<Clone>$";
    var cloneMethodBuilder = derivedTypeBuilder
      .DefineMethod(cloneMethodName, MethodAttributes.Public | MethodAttributes.Virtual | MethodAttributes.HideBySig, derivedTypeBuilder, null)
      .SetCtorAttribute<PreserveBaseOverridesAttribute>()         // <Clone>$ メソッドにコンストラクタ系属性を追加する
      .SetCtorAttribute<CompilerGeneratedAttribute>();
    var il                 = cloneMethodBuilder.GetILGenerator(); // IL ジェネレーターを取得し、<Clone>$ メソッドの本体を生成する
    var baseCloneMethod    = baseType                             // <Clone>$ メソッドを基底クラスのメソッドとしてオーバーライドする
      .GetMethod(cloneMethodName, BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance)
      ?? throw new NotImplementedException($"Method {cloneMethodName}() on {baseType.Name} was not found.");

    derivedTypeBuilder                                            // Override
      .DefineMethodOverride(cloneMethodBuilder, baseCloneMethod);

    il.Emit(OpCodes.Ldarg_0);                                     // IL コードとして、自分自身をロード
    il.Emit(OpCodes.Newobj, derivedCtorBuilder);                  // 新しいインスタンスを作成するためにコンストラクタを呼び出す
    il.Emit(OpCodes.Ret);                                         // 戻り値として返す

    return cloneMethodBuilder;
  }

  // TypeBuilder にテーブル属性を付与する
  private static TypeBuilder SetTableAttribute(this TypeBuilder typeBuilder, string tableName, string schemaName) {
    var attribType     = typeof(TableAttribute);
    var attribCtor     = attribType.GetConstructor(new[] { typeof(string) })   ?? throw GetException_("Constructor .ctor(string)");
    var attribProperty = attribType.GetProperty(nameof(TableAttribute.Schema)) ?? throw GetException_("Property .Schema");
    var attribBuilder  = new CustomAttributeBuilder(attribCtor, new object[] { tableName }, new[] { attribProperty }, new object[] { schemaName });

    typeBuilder.SetCustomAttribute(attribBuilder);

    return typeBuilder;

    // local method ********************
    static Exception GetException_(string message) =>
      new NotImplementedException($"{message} on the attribute '{nameof(TableAttribute)}' was not found.");
  }

  // MethodBuilder にコンストラクタ系属性を付与する
  private static MethodBuilder SetCtorAttribute<TAttribute>(this MethodBuilder methodBuilder) where TAttribute : Attribute {
    var attrib = typeof(TAttribute);
    var ctor   = attrib.GetConstructor(Type.EmptyTypes)
      ?? throw new NotImplementedException($"Constructor .ctor() on {attrib.Name} was not found.");

    methodBuilder.SetCustomAttribute(new CustomAttributeBuilder(ctor, new object[] {}));

    return methodBuilder;
  }
}

using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations.Schema;
using System.Linq;
using System.Reflection;
using System.Text.RegularExpressions;

// ユーティリティ
public static ExtensionGeneric {
  public static T1 As<T1>(this T1 target, out T1 val1) =>
    val1 = target;

  public static string Join(this IEnumerable<object> source, string delimiter) =>
    string.Join(delimiter, source.Select( x => x.ToString() ));

  public static TFormat New<TFormat>(this Type type) where TFormat : Format =>
    type.IsAssignableTo(typeof(TFormat)) switch {
      true => (TFormat)(type.GetDefaultInstance() ?? throw new NotImplementedException($"Default constructor on {type.Name} wan not found.")),
      _    => throw new ArgumentException($"{type.Name} is not assignable to {typeof(TFormat).Name}."),
    };

  public static string RegexReplace(this string target, string pattern, Func<string[], string> replacer, RegexOptions option = RegexOptions.None) =>
    Regex.Replace(target, pattern, new MatchEvaluator( m => replacer(m.Groups.Cast<Group>().Select( x => x.ToString() ).ToArray()) ), option);

  public static object? GetDefaultInstance(this Type type) =>
    type.GetConstructor(Type.EmptyTypes)?.Invoke(null);

  public static string ToStructureString(this Type type) =>
    (type.GetCustomAttribute<TableAttribute>() switch {
      {} attrib => new[] { $"[Table(\"{attrib.Name}\", Schema = \"{attrib.Schema}\")]" },
      _         => Enumerable.Empty<string>(),
    })
      .Append($"{type} : {$"{type.BaseType}".RegexReplace(@"^.*?([^\.]+)$", m => m[1])} {{")
      .Concat(type
        .GetProperties()
        .Select( x => $"  public {x[0]} {x[1]} {{ get; init; }}" ))
      .Append("}")
      .Join(Environment.NewLine);
}

var type = DynamicFormatCreator.CreateFormat<BaseFormat>("DerivedFormat202308", "table_derived202308", "olap");
var inst = type.New<BaseFormat>() with {
  id   = 1,
  text = "test",
};

Console.Error.WriteLine(type.ToStructureString());

// displayed as follows:
//
// [Table("table_derived202308", Schema = "oltp")]
// public record DerivedFormat202308 : BaseFormat {
//  public int    id   { get; init; }
//  public string text { get; init; }
// }

Console.Error.WriteLine(inst);

// displayed as follows:
// 
// DerivedFormat202308 { id = 1, text = test }

ポイント

ポイントはこういうことだった。

• デフォルトコンストラクタ new TDerivedFormat() を IL で定義するだけではダメ。<Clone>$() という隠れクローンメソッドを定義しなければ。
• <Clone>$() という隠れクローンメソッドを定義するだけではダメ。それをオーバーライドメソッドとして定義しなければ。
• <Clone>$() という隠れクローンメソッドをオーバーライド定義するだけではダメ。自己参照型コンストラクタ new TDerivedFormat(TBaseFormat that) を定義しなければ。

まあ、本来の record クラスは Equals() や GetHashCode() なども定義しなければならないため、また、本来の派生クラスは基底の定義に加えてプロパティやメソッドがありこれも定義すべきであるため、本当の継承では書くべきコード量はもっと増えるのだが。
いまのままでは、定義が不足しているメソッドはおそらく基底クラスのそれが用いられる。ここでは、具象クラスであることと Table 属性が付与されていることだけが派生クラスと基底クラスの相違点で、プロパティもメソッドも全く同じである、という形でしか使わないため、ここまでにする。

*1:このトピックはここで考察している。→ PythonのDjangoのデータベース操作。ORMと生Queryどっちを使う方がいいのでしょうか？（ORMで調べても出来ない作業を生Queryでやってもええんやろか）に対するNiwa Yosukeさんの回答 - Quora

*2:クエリビルダの長所は SQL を自由に組めること。対する短所はデータコンテナの型安全性が担保されないテキスト編集であること。ここを改善したのが DbExtensions ライブラリだが、これでもまだ少し不満がある。

*3:DbExtensions を用いてもまだ残る不満は、EntityFrameworkCore の IQueryable<T> のようにデータコンテナ T に対する型安全性と再利用性・応用性が高くないこと。要はプリミティブ型ではなく "データコンテナ T" に着目した関数型プログラミングで Fluent API 的に流れるように書きつつ、それでいて似たデータコンテナやコード片を使い回せるようにしてコード記述量を極小化したい。そうしないとクエリの可読性が向上せず、メンテナンスが大変になる。

Programming w/ PostgreSQL ～ テーブル・レコード更新日時の記録

PostgreSQL のテーブルにレコード更新された日時を記録する実験

仕掛けづくりは下記の通り。

-- [初期設定] スキーマ作成
CREATE SCHEMA sandbox;

-- [初期設定] 観測対象テーブルのレコード最終更新日時を記録するテーブルの定義
CREATE TABLE IF NOT EXISTS sandbox.table_last_modified (
  table_name       TEXT      PRIMARY KEY,
  last_modified_at TIMESTAMP
);

-- [初期設定] レコード更新時に発動する関数の定義
CREATE OR REPLACE FUNCTION sandbox.update_table_last_modified() RETURNS trigger AS $$
BEGIN
  -- レコード更新されたテーブル名と現在時刻を挿入・更新する
  INSERT INTO sandbox.table_last_modified (table_name, last_modified_at) VALUES (TG_TABLE_NAME, CURRENT_TIMESTAMP)
  ON CONFLICT (table_name) DO UPDATE SET last_modified_at = CURRENT_TIMESTAMP;
  RETURN NULL;
END;
$$ LANGUAGE plpgsql;

-- [テーブル作成都度] 観測対象テーブルの定義
CREATE TABLE IF NOT EXISTS sandbox.table_observable (
  id   INTEGER PRIMARY KEY,
  text TEXT
);

-- [テーブル作成都度] 観測対象テーブルに対するトリガーの設定
CREATE TRIGGER sandbox.test_last_modified
AFTER INSERT OR UPDATE OR DELETE ON sandbox.table_observable 
FOR EACH STATEMENT EXECUTE PROCEDURE update_table_last_modified();

実行結果

観測対象テーブルにも更新記録テーブルにも、初めは何も入っていない。

SELECT * FROM sandbox.table_observable;
--|id|text|
--|  |    |

SELECT * FROM sandbox.table_last_modified;
-- |table_name|last_modified_at|
-- |          |                |

観測対象テーブルに１行挿入してみる。

INSERT INTO sandbox.table_observable VALUES (1, 'test');

観測対象テーブルには１行挿入され、更新記録テーブルにもレコード更新の記録が残る。

SELECT * FROM sandbox.table_observable;
--|id|text|
--| 1|test|

SELECT * FROM sandbox.table_last_modified;
-- |table_name      |last_modified_at          |
-- |table_observable|2023-08-11-22:22:22.222222|

利用例

レコード最終更新日時も同時に取得したいとき、このように使ったらよいのではないか。
ただし、最終更新日時カラムの情報は各レコードごとの更新情報ではなく、テーブルのそれである。OLAP ではデータキューブの一括更新時刻を知りたいことがある *1 。

WITH qry AS (SELECT last_modified_at FROM sandbox.table_last_modified WHERE table_name = 'table_observable')
SELECT tbl.*, (SELECT qry.last_modified_at FROM qry) FROM sandbox.table_observable AS tbl;

-- |id|text|last_modified_at          |
-- | 1|test|2023-08-11-22:22:22.222222|

*1:レコードごとの最終更新日時を保持・参照したいときは観測対象テーブル側にそのようなカラムを用意すればよい。こちらは OLTP でよくやる通常の方法。

Programming w/ PHP ～ PostgreSQL への接続

メモ

<?php
$host   = "";
$dbname = "";
$user   = "";
$passwd = "";

$conn = pg_connect("host=$host dbname=$dbname user=$user password=$passwd");

if (!$conn) {
  $error = pg_last_error(); // エラーの取得
  echo "接続失敗";
  exit;
}

$query = "SELECT * FROM xxx;";
$result = pq_query($conn, $query);

while ($row = pg_fetch_assoc($result)) {
  echo $row['column'] . "<br>";
}

pg_close($conn);
?>

Programming w/ C# ～ プロパティの型 "定義" の抽出方法 (再訂正・改良版)

プロパティの型 "定義" の抽出方法 (訂正・改良版)

やりたいこと

データを record class 等のコンテナクラスで扱う際、特にそれをデータベースにマップする際に、カラムに対応する各プロパティの正確なデータ型 "定義" をプログラム上で知りたいことがある。
これができるとコードファースト / モデルファースト的にコンテナクラスの情報から CREATE TABLE を実行できる。

問題の背景

C# 標準 ORM の Entity Framework Core ではこの辺りのマッピングがよくできていて、プログラマがやらなければいけないことはあまりない。
Entity Framework Core は ORM としては優秀である一方、複雑な集合演算に弱く、クエリビルダーとしては貧弱であることは否めない。
そこで EntityFramework Core のデータコンテナに対する型安全性を活かしつつ、Dapper や DbExtensions といったクエリビルダーの集合演算に対する柔軟性を併せ持つ、型安全クエリビルダー・ライブラリを構築する。
その際に record class のプロパティ定義から正確なデータ型 "定義" を抽出する必要がある。

難所

これは System.Reflection を用いればできるように見えて、一筋縄ではいかない。プロパティ情報はいちおう typeof(TContainer).GetProperties() とすることで取得できるが、取得した型が string である場合、ヌル非許容参照型 string とヌル許容参照型である string? とを識別できないためだ。.NET 仮想マシンはデータ型としては string? 型は string 型として保持しており、両者の区別がないため、実行コード上では (一見) 識別できないということになる。

var obj = new TContainer();

obj.GetType().GetProperties().Select( p => p.GetValue(obj)?.GetType() );

などとしてもダメ。プロパティのインスタンスから取得しても、そのプロパティに割り付けられている値が string か null かを得るだけでプロパティの型 "定義" 情報を得ることはできない。

知りたいのはコンパイル時の型定義であって、実行時のインスタンス情報ではない。

解決方法

このように記述するとプロパティの型定義を Nullable / Non Nullable の違いを含めて正確に取得できる。
プロパティに対し (Nullable を外した型名、Nullable であるか否か) とタプルにした情報を返す。

  public static (Type Type, bool IsNullable) GetTypeExact(PropertyInfo prop) =>
    prop.PropertyType switch {
      var pType when pType.IsEnum                              => (pType                         , false                            ),
      var pType when pType.IsGenericTypeOf(typeof(Nullable<>)) => (pType.GetGenericArguments()[0], true                             ),
      var pType when pType.IsValueType                         => (pType                         , false                            ),
      var pType                                                => (pType                         , IsNullableReferenceProperty(prop)),
    };

  public static bool IsNullableReferenceProperty(PropertyInfo prop) {
    return (GetNullableFlagFirst_(prop) ?? GetNullableContextFlag_(prop)) switch {
        0    => ! prop.PropertyType.IsValueType, // 参照型なら Null 許容, 値型なら Null 非許容 (C# 7 or former 後方互換)
        1    => false                          , // Null 非許容
        2    => true                           , // Null   許容
        null => throw new NotImplementedException("NullableFlags or Flag argument failed to be obtained."),
        _    => throw new NotImplementedException("NullableFlags or Flag instance is an unexpected value (other than 0, 1 or 2)."),
    };

    // local method ********
    // [Nullable(byte[] NulableFlags = new[] { 0 or 1 or 2 })] 属性から 0, 1, 2, null (属性なし) を抽出する
    static byte? GetNullableFlagFirst_(PropertyInfo prop) =>
      (prop.GetCustomAttributes()
        .FirstOrDefault( a => a.GetType().FullName == "System.Runtime.CompilerServices.NullableAttribute" )
          .As(out var attrib)
          ?.GetType().GetField("NullableFlags")
          ?.GetValue(attrib) as byte[])?[0];

    // [NullableContext(byte Flag = 1 or 2)] 属性から 1, 2, null (属性なし) を抽出する (C# 8 では属性付与されないため非有効)
    static byte? GetNullableContextFlag_(PropertyInfo prop) =>
      prop.DeclaringType!.GetCustomAttributes()
        .FirstOrDefault( a => a.GetType().FullName == "System.Runtime.CompilerServices.NullableContextAttribute" )
        .As(out var attrib)
        ?.GetType().GetField("Flag")
        ?.GetValue(attrib) as byte?;
}

public static class Extension {
  // 後方参照用中間変数定義ユーティリティ・拡張メソッド
  public static T1 As<T1>(this T1 target, out T1 val1) =>
    val1 = target;
}

あとは下表のように、得られた型と Nullable / NonNullable 情報を元にデータベースの型へマップしてやるだけ。

C#	PostgreSQL
int	INTEGER NOT NULL
int?	INTEGER
double	DOUBLE PRECISION NOT NULL
double?	DOUBLE PRECISION
string	TEXT NOT NULL
string?	TEXT

ポイント

• string と string? は、型では識別できないため、System.Runtime.CompilerServices.NullableAttribute と .NullableContextAttribute という属性にて識別する。
  • プロパティに NullableAttribute 属性が付されているか否かを調べ、その NullableFlags フィールド (byte[]) の第１要素 *1 を調べる。
    • 0 ならばその要素が値型か参照型かで null 許容/非許容が決まる *2 。値型は非許容、参照型は許容。
    • 1 ならば null 非許容参照型。(string)
    • 2 ならば null 許容参照型。(string?)
  • ただし、NullableAttribute 属性が付されていない場合もある。そのときは当該プロパティを包含するクラスに NullableContextAttribute 属性が付されているか否か *3 を調べ、その Flag フィールド (byte) を調べる。
    • 1 ならば null 非許容参照型。(string)
    • 2 ならば null 許容参照型。(string?)
  • プロパティの NullableAttribute 属性の前にクラスの NullableContextAttribute 属性で定義されている *4 ということなのだろう。
• ヌル許容値型 (int? など) には属性 NullableAttribute は付与されない。
  • 値型の Nullable / NonNullable 判定には .IsGenericTypeOf(typeof(Nullable<>)) を用い、nullable の原型判定には .GetGenericArguments()[0] を用いる。
• 属性 NullableAttribute はプロパティに、属性 NullableContextAttribute はそれを包含するクラスに付与され存在しうるが、当該属性はシステム管理用であるため、プログラマが直接操作することはできない。
  • そのため、.GetCustomAttribute<NullableAttribute>() などとして属性クラス指定で判定することはできず、全属性をいったん文字列化してから NullableAttribute や NullableContextAttribute の存在を判定する。

*1:属性のコンストラクタ第１引数を調べてはいけない。フィールドは常に byte[] 型だが、C# 言語バージョンによってコンストラクタは byte[] だったり byte だったりする。仕様変更があったようだ。

*2:これはおそらく C# 7 以前に対する後方互換性。

*3:NullableContextAttribute は C# 8 では機能しない。C# 8 は Nullable の扱いが不完全であった。

*4:ただ、NullableContextAttribute がどのように決まり、スイッチされるか C# コンパイラ内部仕様は不明。nullable コンテクストを変えていない同一プロジェクト、同一モジュール内において同一のプロパティ定義をしているクラス間でもこの NullableContextAttribute 属性が異なるケースがあった。

Programming w/ C# ～ 鬼滅の刃コラボ 無限列車編

鬼滅の刃 無限列車編

C#er は、鬼滅の刃 無限列車編 をこう見る。(下記コード部分にはネタバレを含みます。)
NotImplemented はきちんと実装しないと使えませんよ。

using System;
using System.Collections.Generic;
using System.Linq;
using ヒノカミ神楽 = 日の呼吸;

public interface 日の呼吸 {
  public    object? 壱ノ型_円舞()            => throw new NotImplementedException();
  public    object? 弐ノ型_碧羅の天()        => throw new NotImplementedException();
  public    object? 参ノ型_烈日紅鏡()        => throw new NotImplementedException();
  public    object? 肆ノ型_灼骨炎陽()        => throw new NotImplementedException();
  public    object? 伍ノ型_陽華突()          => throw new NotImplementedException();
  public    object? 陸ノ型_日暈の龍_頭舞い() => throw new NotImplementedException();
  public    object? 漆ノ型_斜陽転身()        => throw new NotImplementedException();
  public    object? 㭭ノ型_飛輪陽炎()        => throw new NotImplementedException();
  public    object? 玖ノ型_輝輝恩光()        => throw new NotImplementedException();
  public    object? 拾ノ型_火車()            => throw new NotImplementedException();
  public    object? 拾壱ノ型_幻日虹()        => throw new NotImplementedException();
  public    object? 拾弐ノ型_炎舞()          => throw new NotImplementedException();
  protected object? 拾参ノ型()               => throw new NotImplementedException(); // 後ほど public に修正します
  public    void    回復の呼吸()             { /* ... */ }
  public    void    全集中の呼吸()           { /* ... */ }
  public    void    全集中_常中()            { /* ... */ }
}

public interface 炎の呼吸 : 日の呼吸 { // すべての呼吸は始まりの呼吸の派生 ... のはずなのだが、基底インターフェースのメソッドを実装してないね
  public object? 壱ノ型_不知火()       { /* ... */ } // 無限列車内・対 上弦の参 猗窩座戦で利用
  public object? 弐ノ型_昇り炎天()     { /* ... */ } // 炭治郎防護に利用
  public object? 参ノ型_気炎万象()     { /* ... */ } // 映画/劇場版小説オリジナル
  public object? 肆ノ型_盛炎のうねり() { /* ... */ } // 破壊殺・空式に対応
  public object? 伍ノ型_炎虎()         { /* ... */ } // 破壊殺・乱式に対応
  // 陸・漆・捌ノ型は Obsolete ではないよね ... ?
  public object? 玖ノ型_奥義_煉獄()    { /* ... */ } // 破壊殺・滅式に対応
}

public interface 水の呼吸 : 日の呼吸 {
  public object? 壱ノ型_水面斬り()    { /* ... */ }
  public object? 弐ノ型_水車()        { /* ... */ }
  public object? 参ノ型_流流舞い()    { /* ... */ }
  public object? 肆ノ型_打ち潮()      { /* ... */ }
  public object? 伍ノ型_干天の慈雨()  { /* ... */ }
  public object? 陸ノ型_ねじれ渦()    { /* ... */ }
  public object? 漆ノ型_雫波紋突き()  { /* ... */ }
  public object? 捌ノ型_滝壷()        { /* ... */ }
  public object? 玖ノ型_水流飛沫_乱() { /* ... */ }
  public object? 拾ノ型_生生流転()    { /* ... */ }
  public object? 拾壱ノ型_凪()        => throw new NotImplementedException(); // 義勇さんだけが実装してるよ
}

public interface 雷の呼吸 : 日の呼吸 {
  public object? 壱ノ型_霹靂一閃() { /* ... */ }
  public object? 弐ノ型_稲魂()     { /* ... */ }
  public object? 参ノ型_聚蚊成雷() { /* ... */ }
  public object? 肆ノ型_遠雷()     { /* ... */ }
  public object? 伍ノ型_熱界雷()   { /* ... */ }
  public object? 陸ノ型_電轟雷轟() { /* ... */ }
  public object? 漆ノ型_火雷神()   => throw new NotImplementedException(); // 善逸だけが実装することになるよ
}

public interface 獣の呼吸 : 日の呼吸 { // 風の呼吸に似ているが、派生ではない
  public object? 壱ノ牙_穿ち抜き()      { /* ... */ }
  public object? 弐ノ牙_切り裂き()      { /* ... */ }
  public object? 参ノ牙_喰い裂き()      { /* ... */ }
  public object? 肆ノ牙_切細裂き()      { /* ... */ }
  public object? 伍ノ牙_狂い裂き()      { /* ... */ }
  public object? 陸ノ牙_乱杭咬み()      { /* ... */ }
  public void    漆ノ型_空間識覚()      { /* ... */ }
  public void    捌ノ型_爆裂猛進()      ;
  public object? 玖ノ牙_伸_うねり裂き() ;
  public object? 拾ノ牙_円転旋牙()      ;
}

public interface 血鬼術 {
  public void 再生() { /* ... */ }
}

public interface 爆血 : 血鬼術 {
  public object? 爆血() { /* ... */ }
}

public interface 瑠火の言葉 {
  public void 強く生まれた者の責務を果たす() { /* ... */ } // ここにいる者は誰も死なせない
  public void あとを託す()                   { /* ... */ } // 竈門少年, 猪頭少年, 黄色い少年 ...
}

public interface 柱 {
  public void 後輩の盾となる() { /* ... */ } // 柱ならば後輩の盾となるのは当然だ 柱ならば誰であっても同じことをする 若い芽は摘ませない
}

public class 煉獄杏寿郎 : 炎の呼吸, 柱, 瑠火の言葉 { // 基本に忠実で独自実装がない ... 至高の領域に近い？
}

public class 竈門炭治郎 : ヒノカミ神楽, 水の呼吸 { // 無限列車編 : ヒノカミ神楽のメソッドはまだ 2 つしか実装していないよ
  public    object? 壱ノ型_円舞()            { /* ... */ } // 那田蜘蛛山 対 下弦の伍 累戦で利用
  public    object? 弐ノ型_碧羅の天()        { /* ... */ } // 対 下弦の壱 魘夢戦で利用
  public    object? 参ノ型_烈日紅鏡()        => null; // 実装中 (until 遊郭編)
  public    object? 肆ノ型_灼骨炎陽()        => null; // 実装中 (until 遊郭編)
  public    object? 伍ノ型_陽華突()          => null; // 実装中 (until 刀鍛冶の里編)
  public    object? 陸ノ型_日暈の龍_頭舞い() => null; // 実装中 (until 刀鍛冶の里編)
  public    object? 漆ノ型_斜陽転身()        => null; // 実装中 (until 無限城編)
  public    object? 㭭ノ型_飛輪陽炎()        => null; // 実装中 (until 無限城編)
  public    object? 玖ノ型_輝輝恩光()        => null; // 実装中 (until 無限城編)
  public    object? 拾ノ型_火車()            => null; // 実装中 (until 遊郭編)
  public    object? 拾壱ノ型_幻日虹()        => null; // 実装中 (until 遊郭編)
  public    object? 拾弐ノ型_炎舞()          => null; // 実装中 (until 遊郭編)
  protected object? 拾参ノ型()               => null; // 実装中 (until 無限城編)
  public    object? 円舞一閃()               => null; // 実装中 (until 刀鍛冶の里編)
}

public class 竈門禰豆子 : 爆血 {
  public object? 爪で引き裂く() { /* ... */ }
  public object? 蹴る()         { /* ... */ }
  public void    鬼化進行()     {}            // 実装中 (until 遊郭編)
  public object? 解毒()         => null;      // 実装中 (until 遊郭編)
  public object? 爆血刀()       => null;      // 実装中 (until 刀鍛冶の里編)
  public void    太陽克服()     {}            // 実装中 (until 刀鍛冶の里編)
}

public class 嘴平伊之助 : 獣の呼吸 {
  public void    捌ノ型_爆裂猛進()      {}       // 実装中 (until 遊郭編)
  public object? 玖ノ牙_伸_うねり裂き() => null; // 実装中 (until 無限城編)
  public object? 拾ノ牙_円転旋牙()      => null; // 実装中 (until 無限城編)
  public object? 思いつきの投げ裂き()   => null; // 実装中 (until 無限城編)
}

public class 我妻善逸 : 雷の呼吸 {
  public IEnumerable<object?> 壱ノ型_霹靂一閃_六連() => Enumerable.Repeat((this as 雷の呼吸).壱ノ型_霹靂一閃(), 6);
  public IEnumerable<object?> 壱ノ型_霹靂一閃_八連() => null!;                               // 実装中 (until 遊郭編)
  public object?              壱ノ型_霹靂一閃_神足() => null;                                // 実装中 (until 遊郭編)
  public object?              弐ノ型_稲魂()          => throw new NotImplementedException(); // 頑張ってください善逸君 一番応援してますよ
  public object?              参ノ型_聚蚊成雷()      => throw new NotImplementedException(); // 頑張ってください善逸君 一番応援してますよ
  public object?              肆ノ型_遠雷()          => throw new NotImplementedException(); // 頑張ってください善逸君 一番応援してますよ
  public object?              伍ノ型_熱界雷()        => throw new NotImplementedException(); // 頑張ってください善逸君 一番応援してますよ
  public object?              陸ノ型_電轟雷轟()      => throw new NotImplementedException(); // 頑張ってください善逸君 一番応援してますよ
  public object?              漆ノ型_火雷神()        => null;                                // 実装中 (until 無限城編)
}

実装中 = 修行により確立
将来予約 = 実戦中に獲得

Programming w/ C# ～ DocFx の利用方法

はじめに

Java の javadoc のように C# においても /// がドキュメントコメントになることは知っており VS Code にもそれ用の拡張機能を加えていた。しかし、これまできちんと運用したことがなかったため、ここらで導入してみることにした。(DoxFx は 2.61.0 時点でまだまだバグがたくさんありそうだ。)
DocFx で Web ページのセットを構築するには、けっこう注意点があるため、ここに記録する。

運用方法

以下のように運用すると非常に便利。

1. ソースコードとは独立した場所に仕様文書専用フォルダを切る。
2. すべてのプロジェクトはそのサブフォルダに文書化する。
3. 各プロジェクトの仕様文書専用フォルダに docfx.json を配置し、そのフォルダを working dir として docfx を起動する doc タスク定義をソースコードの側の .vscode/tasks.json に記述する。
4. 仕様文書専用フォルダを Docker の Apache で常時 Web 展開する。

VS Code タスク設定

ビルド中間生成物や DocFx のキャッシュなどが悪さをすることがあるため、clean コマンドも整備しておく。

    {
      "label": "doc",
      "type": "shell",
      "command": "docfx",
      "args": [
        "...(仕様文書専用フォルダ)...\\...(プロジェクトサブフォルダ)...\\docfx.json",
        "--cleanupCacheHistory",
      ],
      "group": {
        "kind": "build",
        "isDefault": true,
      },
      "presentation": {
        "reveal": "always",
        "clear": true,
      },
    },
    {
      "label": "clean",
      "type": "shell",
      "command": ".vscode\\_clean.bat",
      "args": [
      ],
      "group": {
        "kind": "build",
        "isDefault": true,
      },
      "presentation": {
        "reveal": "always",
        "clear": true,
      },
    },

クリーンアップバッチは各自の環境におけるビルド出力先 obj フォルダ, bin フォルダに応じて設定する。

@echo off
dotnet clean --nologo
rd /s /q bin
for /f "usebackq tokens=1 delims==" %%d in (`dir /d /b /s ^| findstr /e \\obj ^| findstr /v \\obj\\`) do rd /s /q %%d

名前空間ページの作成

名前空間のページを作成するには namespaces フォルダを新設し、下記のようにアクセスを許可しておく。

    "overwrite": [
      {
        "files": [
          "namespaces/**.md"
        ]
      }
    ]

そして、各名前空間のページを Markdown で記述する。uid には名前空間の識別子を、summary には *content を指定する。

---
uid: UserLib.Common
summary: *content
---
UserLib.Common 名前空間は, 標準の各種オブジェクト型に対する拡張メソッドまたは機能拡張した派生クラスを扱う.

表示抑制の設定

継承メンバーの表示抑制

継承メンバーの表示が煩わしい場面があるため、以下のようにしてノイズ的な情報を表示抑制する。
filterConfig.yml に正規表現を記述して表示抑制する際は docfx --cleanupCacheHistory で文書ビルドしないと正しく反映されないことが多い。

継承メンバーの項目全消去 (不採用)

継承メンバーの項目全体を消去するには下記を追記する。docfx の出力文書ではなく css で表示を抑制するようだ。ただ一律消去は弊害が大きいため、不採用とする。

inheritedMembers { display: none; }

Obsolete メンバーの消去

Obsolete メンバーを消去するには、スタイル設定ではなく filterConfig.yml が必要だ。filterConfig.yml は Python のようにインデントにセンシティブであることに注意を要する。

  "build": {
    "filter": "filterConfig.yml",
  }

apiRules:
- exclude:
    hasAttribute:
        uid: System.ObsoleteAttribute

下記のように GitHub の Q&A に従うとメンバーではなく [Obsolete] 属性自体しか消えないため注意。これはこれで属性を表示抑制するときに使えるが。
また uidRegex は正規表現であるため、名前空間や引数の揺らぎを吸収するように記述する必要がある。

attributeRules:
- exclude:
    uidRegex: ^System\.Obsolete$

基本クラスのメンバーの消去

System.Object.ToString() などすべてのクラスが継承しているメンバーを Inherited Members に表示されると煩わしいため、消去する。object は SystemObject と object の間で揺らぎがあることに注意。ここでは Member としているが、Field, Event, Method, Property ごとの指定も可能。(.NET API Docs | docfx 参照)

- exclude:
    uidRegex: ^(System\.)?[Oo]bject
    type: Member

ただし、.Equals(),.HashCode(),.SequenceEquals() などを利用して演算子オーバーロードしている演算系ユーティリティなどでは Inherited Members を消去しない方が望ましいと思われる。object のみならず、独自 Exception を定義している場合は System.Exception のメソッドを消去してもよいかもしれない。

- exclude:
    uidRegex: ^(System\.)?Exception
    type: Method

隠蔽した基底クラス・メソッドの消去

基礎ライブラリのメソッドが充実しすぎているためにオーバーライドして隠蔽したケースなどでは基底クラスのメソッド表示を消去する。

- exclude:
    uidRegex: ^DbExtensions.Database
    type: Member

データコンテナのプロパティの消去

コード付帯のオブジェクトというよりは POCO データコンテナとして用いる record class などは各プロパティの個別説明表示ではなく一覧表として remarks タブ内にリスト表示した方が見やすいため、プロパティ表示を消去する。

- exclude:
    uidRegex: ^DataModel\.(.*\.)?ContainerFormat.+
    type: Property

Markdown 記事の追加

Markdown 記事の追加方法

Markdown で追加記事を記述できる。まずは docfx.json ファイル内 buid > content の第２要素 (メニューバー内容相当) に追加することでリソースアクセスを許可する。

  "build": {
    "content": [
      {
        "files": [
          "reference/**.md",
          "reference/**/toc.yml",
        ]
      }
    ]
  }

次にメニューバーにリンクを設ける。

- name: Reference
  href: reference/

そしてフォルダを切って記事を書く。

### API Reference
- [Ms Docs](https://learn.microsoft.com/ja-jp/dotnet/api/)
- [DbExtensions](https://maxtoroq.github.io/DbExtensions/)

toc.yml は左サイドメニューペインのコンテンツになる。ここで Markdown のページ内参照 (# 以降の部分) の記法は、英文字を小文字に、スペースをハイフンに、アンダースコア以外の記号文字を省略にする必要がある。

- name: API Reference
  href: index.md#api-reference

画像等の追加方法

画像等のファイルは Markdown 記事のフォルダに置いても参照できないようだ。working dir 直下に images フォルダを切ってその中に格納する。

    "resource": [
      {
        "files": [
          "images/**"
        ]
      }
    ]

外部リンク動作の設定

外部リンクは別タブで開く設定を Web ページに施す。そのためにまず javascript の格納場所 styles を作る。注意すべきは docfx.json での記述は格納場所のアクセス権の設定でしかないということだ。ここにスクリプトを置いてもそれだけで Web ページに反映されるわけではない。

 "build": {
    "resource": [
      {
        "files": [
          "styles/*.js",
        ]
      }
    ]
  }

javascript コードを記述する。target="_blank" を使う時は rel="noopener noreferrer" の設定も忘れないこと。

$(document).ready( function () {
  $("a[href^='http']").attr('target', '_blank');
  $("a[href^='http']").attr('rel', 'noopener noreferrer');
} );

最後に、適用する Web ページ (Markdown ファイル) の冒頭に下記の 2 行を追記する。各 Web ページに javascript コントロールのインポートを記述しなければ適用されない。また、google api スクリプトのインポートを 2 つ目のスクリプトに内包して動的呼び出しにしようとすると HTML 評価タイミングの関係で動作しなくなるようで script タグは 2 つ記述する必要がある。

<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<script type="text/javascript" src="../styles/target_blank.js"></script>

スタイル設定

事前準備としてスタイル用の javascript, css をアクセス権の専用フォルダに配置する。その上でスタイル記述をしたファイルへの参照をスタイル適用するページに追記する必要がある。

  "build": {
    "resource": [
      {
        "files": [
          "styles/*.js",
          "styles/*.css"
        ]
      }
  }

Programming w/ C# ～ Null 安全なジェネリクスのコード記述方法

null 安全なジェネリクス記法

C# 9.0 からようやく null 安全なジェネリクスがまともに記述できるようになったため nullability について試行錯誤してみた。
C# 9.0 以降の nullable コンテクストはそれなりによくできているが、nullablity 解釈の柔軟さ・厳格さに少し揺らぎもあり、複雑な型パズルに出くわして面食らうことがある。

そこで備忘をここに記録する。

結論

1. 一般に notnull 制限付き T? 記法 (後述 Style 3) を用いるのが望ましい
2. 任意の型 T を入力として受け入れて、出力にその既定値を返す可能性がある場合 (defaultable) は notnull 制限なし T? 記法 (後述 Style 2) を用いる
3. 変数の型推論は柔軟 -- 引数はメソッド適用時により広い型の方へ拡大解釈される
   • int 変数は method<T>(T? parameter) {} や method<T>(T? parameter) where T : notnull {}　に代入可能
   • 変数許容に関して int は null 非許容値型である一方 T? は null 許容型だ、という型相違は警告・エラー報告されない
4. ラムダ式の型推論は厳格 -- ラムダ式のシグニチャは厳格に解釈される
   • ラムダ式は入出力の型の揺らぎを一切許容しないため、必要に応じてキャストすること
   • Func<T?, U> は Func<T, U> より広いが、キャストなしに後者のインスタンスを前者の変数に代入できない
5. Source-Typed だけではなく Target-Typed の推論もあるため、notnull 制約を細かく設定していないと拡大解釈されて矛盾が生じることがある
   • 特に Interface 制約 (IComparable<T> など) に注意する必要がある
   • 観点 03 のラムダ式入出力からの型推論と合わさると T が int? と推論されて int? 型は IComparable<int?> 準拠ではない、などのエラーになる可能性がある
6. キャストには、Target-Typed 型推論が誤って連鎖・波及することがないよう、型推論ドミノをブレイクして調整するストッパーの役割がある

メソッドと制約の記法

null 許容も非許容も struct も class にも広く適用できるジェネリクスを記述しようと思ったら、理論上は下記の 4 スタイルが考えられる。

/// Style 0 -- オーバーロード振り分け記法 (NG)
void Method<T>(T  param) where T : struct {} // null 非許容値型
void Method<T>(T? param) where T : struct {} // null 許容値型
void Method<T>(T  param) where T : class  {} // null 非許容参照型
void Method<T>(T  param) where T : class? {} // null 許容参照型

/// Style 1 -- 制約なし T 記法
void Method<T>(T  param) {}

/// Style 2 -- 制約なし T? 記法
void Method<T>(T? param) {}

/// Style 3 -- notnull 制約付き T? 記法
void method<T>(T? param) where T : notnull {}

Style 0 -- オーバーロード振り分け記法

null 許容 / 非許容 × struct / class のうちの 1 パターンに制限してメソッド定義するならば、この記法が正しい。ただ、複数パターンに広く適用できるジェネリクスには適さない。制約はシグニチャに入らずオーバーロードを許さないことから、メソッドの入口で振り分ける方法は不可能。

Style 1 -- 制約なし T 記法

.NET Core 3.1 (C# 8.0) までの記法。 標準ライブラリも C# 8.0 まではこのように記述されていた。*1

/// C# 8.0
public interface IComparer<in T> {
  public int Compare (T x, T y);
}

nullable enable が既定になった C# 9.0 以降のプロジェクトでは基本的に Style 1 で記述しない方がよいだろう。

Style 2 -- 制約なし T? 記法

.NET 5 (C# 9.0) からの記法。標準ライブラリは C# 9.0 からこのように記述されている。*2

/// C# 9.0 -- Style 2
public interface IComparer<in T> {
  public int Compare (T? x, T? y);
}

しかし、この制約のない ? 付与は、T? が何でも許容することは疑う余地がない一方で、 T 自体が null 許容型を許容するのかしないのか曖昧で解りにくい。

Style 2 と defaultable

そもそも、制約なし型引数 T に対する T? は nullable ではなくて defaultable だという話 *3 がある。

任意の型に対して defaultable で返り値を返したい場合は Style 2 を採用する必要がある。これは入力 T に対して出力として既定値である default(T) を返したいが、T が class の場合の default(T) が null になってしまい、型の値域が定義域より広がってしまう (= 入力⊂出力となる) からだ。たとえばこのようなケース。

static TResult? Method<T1, T2, TResult>(this (T1, T2) operands, Func<T1, T2, TResult> func, TResult? defaultValue = default(TResult)) => certainCondition switch {
  true => func(operands.Item1, operands.Item2),
  _    => defaultValue,
};

このケースで注意すべきは、引数初期値を与えている TResult? defaultValue = default(TResult) の部分だ。ここをTResult? defaultValue = default と記述してしまうと TResult が class であれ struct であれ常に null となってしまい、本意とするところと違ってしまう。このメソッドは "出力" 側に TResult? という表記を使用しているが、"入力" (操作したい対象) はあくまで TResult である。既定値を取得すると仮想マシンでは class に対して TResult と TResult? の区別がなくどちらも null を返してきてしまうからコード記述でそれを弁別しつつ受け入れるために TResult? という表記をする、というのが defaultable の意味であろう。

Style 3 -- notnull 制約付き T? 記法

そこで考えられるのは notnull 制約を付した Style 3 だ。

LINQ 拡張ライブラリの自作において比較演算評価式をストラテジーパターン的に外挿することが頻出するため、null を取りうる 2 値の比較用に拡張版 .CompareTo() メソッドを記述したが、この際に (プログラムの動作は変わらないものの) スタイルによってプログラマがコード記述に対して意識・懸念することに違いが現れた。Style 3 で記述するとこうなる。

/// Style3 -- nullable 対応版 CompareTo() メソッド
static int CompareToEachOther<T>(T? x, T? y) where T : notnull, IComparable<T> =>
   x?.CompareTo(y) ?? - y?.CompareTo(x) ?? 0;

Style3 で記述するとあることに気付く。x に int? 値ではなく int 値を代入するとどうなるか。

答えは、引数 T? x に代入されるときに自然にキャストされ、メソッド内部では int? として扱われるため、 ?.CompareTo() も ?? も正しくワークする。

---

Style2 で記述するとどうだろうか。

/// Style2 -- nullable 対応版 CompareTo() メソッド
static int CompareToEachOther<T>(T? x, T? y) where T : IComparable<T> =>
   x?.CompareTo(y) ?? - y?.CompareTo(x) ?? 0;

こちらもほとんど変わり映えしないし、同じように動作はする。が、notnull 制約されていない T 自身に null 許容型が入ったらどうなるかコード記述上の曖昧さが少し気になってしまう。int は IComaparable<int> 準拠であるが、int? は IComaparable<int?> 準拠ではない。

この null 許容の曖昧さに対する懸念は、単純な例では問題にならないが、後述する Target-Typed 型推論が絡むと大きな混乱を招くリスクとなる。Style 3 にすれば安全だというわけではないが、このリスクを回避するため Style 2 は非推奨だ。

---

Style 1 で記述するとこうなる。

/// Style1 -- nullable 対応版 CompareTo() メソッド
static int CompareToEachOther<T>(T x, T y) where T : IComparable<T> =>
   x?.CompareTo(y) ?? - y?.CompareTo(x) ?? 0;

x が nullable か否か表明しておらず x に struct が入るかもしれないにも関わらず、不思議なことにこれも正しくワークする。おそらく x?.CompareTo() という表記から x が null 許容型であることを型推論して Style2 と同じ中間コードを生成しているのだろう。しかし、そうであれば T は int? となるはずであり、制約を IComaparable<int> と解釈していることと矛盾する。

こちらはさすがに値型・参照型の違いを弁別せずにやり過ごすのは心情的に難しく、コード表記上 struct と class とを分離したくなる。とはいえ、Style 0 のように制約違いオーバーロードによって外形的に分岐させることはできないため、リフレクションを用いたランタイムの型ガードになる。

static int CompareToEachOther<T>(T x, T y) where T : IComparable<T> => typeof(T) switch {
  var type when type.IsClass  => x?.CompareTo(y) ?? - y?.CompareTo(x) ?? 0, // Class
  _                           => x .CompareTo(y),                           // ValueType, Enum
};

元のコードで動作する (というかジェネリクスで生成される中間コードはおそらく同等コードになっているはずな) のに、プログラマがここまで記述するのはさすがに開発効率が悪い。コード表記の整合性を採るべきか否か、元のコードで本当に正しく動作するか、にいちいち悩みたくない。したがって Style 1 は非推奨となる。

ラムダ式の型推論と Target-Typed 推論

さて、ここまでの議論であれば、スタイルはいずれでも大した問題にはならずこだわる必要はあまりない。が、スタイルを曖昧にしていると混乱して収拾がつかないことがある。

たとえば、このように IComparable<T> 型を入力とするラムダ式を IComparer<T> 実装クラスへラップするコード記述。

/// IComparable<T> 評価ラムダ式を IComparer<T> 準拠に変換するラッパークラス
public class WrapperComparer<T> : IComparer<T> where T : IComparable<T> {
  private Func<T?, T?, int> Comparer { get; set; }

  public WrapperComparer(Func<T?, T?, int>? comparer = null) =>
    this.Comparer =                     comparer ?? ((T? x, T? y) => (x, y).CompareToEachOther());  // for Style 2 or 3

#if __Style_1__
  public WrapperComparer(Func<T , T , int>? comparer = null) =>
    this.Comparer = (Func<T?, T?, int>)(comparer ?? ((T  x, T  y) => (x, y).CompareToEachOther())); // for Style 1 : Func<T, T, int> → Func<T?, T?, int> casting required
#endif

  public int Compare(T? x, T? y) => this.Comparer(x, y);
}

前述の LINQ に比較演算評価式を外挿する場面において、比較演算評価式である IComparable<T>型入力のラムダ式を拡張ライブラリ内では IComparer<T> 準拠クラスへラップする設計としたい。なぜなら、LINQ 標準ライブラリは評価戦略として IComparable<T> 型入力のラムダ式ではなく IComparer<T> 準拠クラスを要求するのが既定となっているからだ。IComparer<T> は応用が利いて悪くないのだが、いちいちクラス定義しなければならず大仰だ。

上記のコードは完成形だが、ここに至るまでに紆余曲折があり、大いに悩まされたことが 1 つある。

当該ラッパークラスは IComparer<T> 準拠であるため、int Compare(T? x, T? y) を実装する必要がある。すなわち Func<T?, T?, int> 型だ。一方これに充て込むために外挿するラムダ式は IComparable<T> 準拠のFunc<T, T, int> 型である。

ラッパークラスのコンストラクタに Style 1 の T where T : IComparable<T> 型入力のラムダ式を与えると、IComparable<T> 制約に基づく入力 Func<T, T, int> を IComparer<T> 準拠クラスが保持する評価式プロパティ Func<T?, T?, int> にマップする際に nullability の違いが浮き彫りになる。

T 型のインスタンスを T? 型の引数やプロパティが受け入れるのとは異なり、Func<T, T, int> 型のインスタンスを、間口がより広いはずの Func<T?, T?, int> 型の引数やプロパティは受け入れない。ラムダ式に対しては、その入出力の型を含めて型の検証が厳格に行われる。

それどころか、Func<T?, T?, int> 型プロパティへ充て込む Func<T, T, int> 型のインスタンスの T は T? 型だろうとTarget-Typed 推論をし、IComparable<T> 制約へ逆適用してしまう。その結果 int? は IComparable<int?>準拠ではないというエラーを発生させる。

Func<T?, T?, int> における T? の T が int だとすると T? は int? であり、この int? が Target-typed 推論で Func<T, T, int> の T にマップされると IComparable<T> は IComparable<int?> だということになってしまう。

このギャップを防ぐには Func<T, T, int> を Func<T?, T?, int>へと Func の入力型違いをキャストする *4 しかない。そしてこれは、アドホックな回避策などではなく、他の制約と不整合を起こさせないために積極的に打つべき抜本策だ。波及していく型推論ドミノが誤っていたら野火の延焼になる。火元から離れて火事になると原因がわからず大きな混乱となる。キャストには延焼を止めるためのドミノ・ストッパーという重要な役割がある。

*1:https://learn.microsoft.com/ja-jp/dotnet/api/system.collections.generic.icomparer-1.compare?view=netcore-3.1

*2:https://learn.microsoft.com/ja-jp/dotnet/api/system.collections.generic.icomparer-1.compare?view=net-5.0

*3:https://ufcpp.net/study/csharp/resource/nullablereferencetype/?p=3#unconstrained-generics

*4:間口のより広い方へのキャストだから問題ない。