2023-02-01

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

Computer

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

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

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

結論

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

2023-01-26

Programming w/ C# ～ステップカウンタ

Computer

C# ソースの (フォルダ再帰的な) ステップカウンタ

ソースコードのファイル数・行数を簡便に知りたい。
dir /b /s から find /v /c へ繋いでワンライナー的にやれば ... といつも思って検索をかけるものの、なかなかズバリの解が出てこないため、バッチファイルでステップカウンタを自作した。

@echo off

setlocal enabledelayedexpansion

for /f "usebackq delims=" %%f in (`dir *.cs /b /s ^| findstr /v "\obj"`) do (
  for /f "usebackq delims=" %%c in (`type %%f ^| find /v /c ""`) do (
    set /a LINES+=%%c
    set /a FILES+=1
    set COUNT=     %%c

    echo !COUNT:~-5! %%f
  )
)

set LINES=     !LINES!
echo ---------------------------------------------------------------------------
echo !LINES:~-5! line(s) in !FILES! file(s).

endlocal

dir /b /s コマンドで .cs ファイルの名称をフォルダ再帰で取得し、findstr /v コマンドで \obj フォルダ格納分を対象から除く。
ファイルを１つ１つ find /v /c へ喰わせて行数カウントし LINES 変数へ加算、同時にFILES 変数でファイル数をカウントする。
あとは各ファイルの行数をファイル名、総計を左空白パディングして出力。

実質は 1 重ループであるにも関わらず、コマンド実行結果を変数に割り当てるための 2 つ目の for 文がちょっとイケていない。

C# ソースの (フォルダ再帰的な) 正規表現マッチング

もう一つおまけに、ファイル再帰的に正規表現マッチングするバッチファイルも作ってみた。(文字/改行コード = UTF8/LF 用)

@echo off

setlocal enabledelayedexpansion

set FCNTSUM=0
set LCNTSUM=0
rem DO NOT TRIM BLANK LINES, because the following THREE lines define a variable for an LF character
set LF=^



cls
chcp 65001 >nul

for /f "usebackq delims=" %%f in (`dir *.cs /b /s ^| findstr /v "\obj"`) do (
  set LCNT0=0
  set CONTENT=

  for /f "usebackq delims=" %%c in (`type %%f ^| findstr /n /r /c:%1 %2 %3 %4 %5 %6 %7 %8 %9`) do (
    set /a LCNT0+=1
    set CONTENT=!CONTENT!%%c
    set CONTENT=!CONTENT!!LF!
  )

  if not "!LCNT0!"=="0" (
    set /a FCNTSUM+=1
    set /a LCNTSUM+=!LCNT0!
    set LCNT1=     !LCNT0!
    set LCNT2=!LCNT1:~-5!
    set HEADER=[!LCNT2!][%%f] ------------------------------------------------------------------------------------------

    echo !HEADER:~0,116!
    echo !CONTENT!
    echo.
  )
)

echo ===================================================================================================================
echo !LCNTSUM! line(s) hit in !FCNTSUM! file(s).

endlocal

!CONTENT! に %%c と !LF! とを結合するのを 2 回に分けるのは %%c の文字列内容に ! が入ると、対象文字列とコンテクストと混同して ! の認識が逆転し、バグり程度がひどくなる (コンテクスト中の !LF! の LF が文字列に埋め込まれてしまう) から。

文字列中の ! を ^! へ置換すればよい*1、変数中の文字列置換はこう*2すればよいとのことだが、! のような特殊文字はバッチ処理では置換できないようだ。文字列とコンテクストの区別がつかないし、文字列の変換もできないとはなんと出来の悪い言語仕様だ。

バッチファイル書くのしんどい ... 動的型付け言語は好きじゃない。

*1:遅延環境変数の展開を利用する際に、エクスクラメーションマーク(感嘆符)をエスケープする - mk_55's diary

*2:[Windowsバッチ] 文字列の文字を置き換える | ぱそまき

2023-01-14

Programming w/ C# ～ record に対する override method

Computer

備忘録

原因不明の不具合に悩まされ、調べたら C# 言語仕様だったということがあったためメモ。

record の override method は class のそれと違う動作をする。

using System;

public class Class1 {
  public string PropC1 = "PropC1";
  public override string ToString() => "Class1";
}

public class Class2 : Class1 {
  public string PropC2 = "PropC2";
}

public record Record1 { 
  public string PropR1 = "PropR1";
  public /* sealed */ override string ToString() => "Record1";
}

public record Record2 : Record1 {
  public string PropR2 = "PropR2";
}

Console.WriteLine($"{new Class1()}");
Console.WriteLine($"{new Class2()}");
Console.WriteLine($"{new Record1()}");
Console.WriteLine($"{new Record2()}");

結果 ... class と record で出力が違う！

Class1                                       // Class1 .ToString() was called.
Class1                                       // Class1 .ToString() was called.
Record1                                      // Record1.ToString() was called.
Record2 { PropR1 = PropR1, PropR2 = PropR2 } // object .ToString() was called! Why?

record の (unsealed) override method を派生 record から呼んだ場合、直近の基底 record の method ではなく、最基底 record (つまり object) の method が適用される。

特に .ToString() はユーザ定義した基底 record の method が呼ばれなくて罠になる。解らなくて半日悩んだ。
record は拡張版 class ではなかったかと ...

このあたりの issue に関連しているか。
[Proposal]: Records with sealed base ToString override · Issue #4174 · dotnet/csharplang · GitHub

2023-01-08

Programming w/ C# ～ TypeForwarding

Computer

備忘録

あるアセンブリに定義されているクラスを参照させつつ、その実体を別のアセンブリに転送したいと思い、TypeForwarding を調べてみた。

ufcpp.net
learn.microsoft.com

が、なかなかうまくいかない。情報が少なすぎてよくわからなかったが、中国語で書かれているブログ記事を google 翻訳し、そこに書いてあった一言でようやく何が原因か理解した。

TypeForwardedTo 属性は、配置するアセンブリは変更できるが、名前空間は変更できない。
やりたかったことは、アセンブリの配置変更だけではなく (名前空間を跨ぐ) エイリアス付与だった。

global using を使うか、ラッパークラスを定義するしかないか ...

2022-11-29

Programming w/ C# ～ Nullable とジェネリクス

Computer

備忘録

C# 8.0 から class 型と class? 型が区別されるようになり Null 安全性が高まったが、ジェネリクスでの Nullable の扱いが難しく、特に C# 8.0 と C# 9.0 以降で大きな違いがあるため、後者のスタイルで記述するときのまとめを備忘として記録する。

制約	T として受け入れられる型のパターン
制約	struct	struct?	class	class?
where T : struct	○	×	×	×
where T : class	×	×	○	×
where T : class?	×	×	○	○
where T : notnull	○	×	○	×
制約なし	○	○	○	○
指定不可	○	○	×	×
指定不可	○	○	○	×

結論としては C# 8.0 を用いる場合は記述環境が不完全なため「nullable enable にできるものの enable にせずに従来型で記述する」のが望ましく、新規プロジェクトでは C# 9.0 以降を用いて Null 安全に記述するのが望ましい。

2022-10-17

Functional Programming w/ C# ～ラムダ式の出力からの型推論

Computer

気づき

TypeScript と違って C# はラムダ式の出力の型から型推論できない！

下記の定義 (2) のような、前項の結果を参照・利用する拡張メソッドを定義しようとしていて気づいた。

public static class ExtensionIEnumerable {
  // 定義 (1) ～ 一般形
  public static IEnumerable<TResult> SelectPrevRef<TSource, TResult>(this IEnumerable<TSource> source, TResult initResult, Func<TResult, TSource, TResult> func) {
    var prevResult = initResult;

    return source
      .Select( x => prevResult = func(prevResult, x) );
  }

  // 定義 (2) ～ 初期値省略形
  public static IEnumerable<TResult> SelectPrevRef<TSource, TResult>(this IEnumerable<TSource> source, Func<TResult, TSource, TResult> func) where TResult : new() =>
    source.SelectPrevRef(new TResult(), func)
}

// 利用 ～ AtCoder ARC149 (a)
// ある数字が最大 n 桁連なる数のうち m の倍数となるものの最大値を求める

var answer = Enumerable.Range(1, 9)                       // 数値 digit = 1 ～ 9 に対して実行
  .SelectMany( digit => Enumerable.Range(1, n)            // n 桁まで繰り返し
    .SelectPrevRef(new { Digit = 0, Length = 0, Rem = 0 }, (prev, length) => new {    // ← この初期値 new { Digit = 0, Length = 0, Rem = 0 } の記述を省略したい
      Digit  = digit                      ,               // 数値 digit
      Length = length                     ,               // 長さ length
      Rem    = (prev.Rem * 10 + digit) % m,               // 数値 digit を 1 桁増やした数の剰余 mod m
    } )
  )
  .Where( x => x.Rem == 0 )                               // Rem == 0 抽出
  .GroupMaxBy( x => x.Length )                            // 最大長   選択 (選択項目が最大となる要素を "すべて" 列挙する独自定義メソッド)
  .GroupMaxBy( x => x.Digit )                             // 最大基数 選択
  .FirstOrDefault() switch {
    null  => "-1",                                        // 解なし
    var x => new string((char)('0' + x.Digit), x.Length), // 文字列化 (overflow 対策として数値化回避)
  };

初期値を外から与えない場合は 0 埋めインスタンス new TResult() が与えられたものとしたい。これを隠し引数としてデフォルト引数にするオーバーロードとして定義しようと TResult initResult = new TResult() としたいところだが、new TResult() は定数ではないため、受け付けない。TResult initResult = default(TResult) としようとすると TResult が struct (0 埋めインスタンス) か class (null) で制約を場合分けしなければならず、(同一シグニチャで) 両立できない。

そこで引数で記述せず、この匿名型の初期値 new TResult() をメソッド定義内で与えたいという発想に至る。 Func から出力の型が匿名型 new { int Length, int Rem } であることは理論上は解るはず。しかし TResult 型を単独のメソッド引数として与えないと型推論できないようだ。new TResult() の代わりに source の第一要素を func に適用して TResult 型インスタンスを得てからリフレクションでデフォルトコンストラクタを呼び出してもやはりムリだった。
TypeScript ならできるのに。C# 言語仕様検討チームにプルリクエストしても、これまた、型推論の負荷が高まるからダメとか反対されるのだろうな。

考えてみるとラムダ式出力の匿名型の定義

      Rem    = (prev.Rem * 10 + digit) % m,

のところで、プロパティ Rem が再帰構造になっており、匿名型の型決定において右辺評価が先 (SourceTyped 型推論) か左辺評価が先 (TargetTyped 型推論) かという論点はありそう。これは型推論をいろいろと試すように推論ロジックを改良しないとできそうにない。

この匿名型を事前にクラス定義しても型推論できないとエラーになるため、この再帰構造がエラーの直接の原因ではないが、匿名型＋再帰はもう１つの壁となっている。

2022-10-17

Functional Programming w/ C# ～ラムダ式の出力からの型推論

Computer

気づき TypeScript と違って C# はラムダ式の出力の型から型推論できない！

下記のような、前項の結果を参照・利用する拡張メソッドを定義しようとしていて気づいた。

|cs| // 定義 static IEnumerable SelectPrevRef<TSource, TResult>(this IEnumerable source, Func<TResult, TSource, TResult> func) where TResult : new() { var prev = new TResult();

return source.Select( x => prev = func(prev, x) ); }

// 利用 // 1 ～ 9 のある数字が最大 n 桁連なる数を modulus で割った余りが 0 となるものの最大値を求める

int n = xxxx; // 桁数 int digit = 1; // 1 ～ 9 の数字 int modulus = xxxx; // なんらかの数

Enumerable,Range(1, n) .SelectPrevRef( (prev, length) => new { Length = length, Rem = (prev.Rem * 10 + digit) % modulus; } ) .Where( x => x.Rem == 0 ) // ... 以下略 ||< Func<TResult, TSource, TResult> から出力の型が匿名型 new { int Length, int Rem } であることは理論上は解るはず。だからこの匿名型の初期値は外から与えずメソッド定義内で与えたい。しかし TResult 型を単独のメソッド引数として与えないと型推論できないようだ。 TypeScript ならできるのに。C# 言語仕様検討チームにプルリクエストしても、これまた、型推論の負荷が高まるからダメとか反対されるのだろうな。