immutable

変数の immutability に関する議論、今に始まった話でもないんでしょっちゅう見かけるには見かけるんですけど、まとめ的な話はあんまりきれいにまとまってるところ見かけないなぁとか思ったり。

というので、まだそんなにきれいに整理できてるわけでもないけど、ちょっと書いてみる。

値の不変性

値の不変性にもいくつか種類があって、

1. constant： コンパイル時定数に名前を付けておきたい
   • 扱いが完全にリテラルと一緒になるやつ
     • C# の const
     • C++ の場合、#define の代替としての const
   • ようは、パフォーマンス的な話で、コンパイル時に解決できる値は全部コンパイル時にやっちゃいたいって話
   • ぶっちゃけ、リテラルが定義できるようなものだけ const 付けれればいいのかなぁと
     • C# の場合、整数型と string と enum だけが const になれる
     • C++ は逆に、constexpr ＆ ユーザー定義リテラル認める方向で進化してるっぽいですけど
2. immutable： 初期化時以外は値の変更不可
   • 不用意なタイミングで値が変わって困るくらいなら、そもそも初期化時以外で値の書き換えできないようにしたい
     • 特に、並列処理やってると、よそのスレッドで値書き換えられたりすると意味わからない結果を招く
   • ローカル変数の場合はほとんどの変数が immutable で事足りる
     • 実際、mutable であって欲しいのはループで集計用とかカウンターに使う変数だけ。それ以外で変数を書き換えることってめったにない
3. one-phase construction： データは一気に初期化したい
   • 「x と y は同時には 0 になっちゃいけない」みたいな、複数のメンバーに渡ったデータ検証を考えた時、x と y を別個に set されると一時的とはいえ不整合が起きる
   • コンストラクターでしか値の初期化しないならそういう心配しなくていいよねということ（その意味では 2. の immutable の派生）
   • まあ、コンストラクターに限定する必要はないけど、とにかく、プロパティ値の set は全プロパティ一気にやりたい（なので実は別に immutable と関係ない）

不変なものの作り方

1. の constant の方は古くからある概念なんで割と素直に理解できる話。ただ、C++ の場合は 2. の意味でも const キーワードを使っちゃうんで話が複雑に・・・。その点、まあ、キーワード増えて気持ち悪いのは気持ち悪いけど、const と readonly を分けた C# は正しいと思う。

C# での 2. の immutable の保証、値型の場合には readonly つければ済むことですが、参照型の場合には参照の上書きができないだけで参照先のデータまでは readonly にならないんで、少し工夫が必要というか、クラス作成側で immutable になるようにクラスを作らないとダメ。例えば、

public class Data
{
    public Data(int x, int y) { X = x; Y = y; }
    public int X { get; private set; }
    public int Y { get; private set; }
}

みたいなクラスを作れば、コンストラクター以外で値を変更できない immutable なクラスになる。

C++ みたいに「普段 mutable な型が const キーワード付けた時だけ immutable になる」っていうのは無理。最も、C# でそれが必要になる場面っていうとあんまり思いつかないですが。C++ の場合はパフォーマンスの問題から普段 mutable な型の const 参照を作る機能が必要だったけど、C# の場合にはそもそも class が全部参照なんで。

ちなみに、C# 3.0 で導入された匿名型はこういうタイプの immutable になってる。

2種類の immutable

immutable には2種類考え方があって、

1. 内部的に immutable
   • private メンバー含め、全部がほんとに初期化時以外書き換わらない
2. 見かけ上 immutable
   • public なメンバーが初期化時以外で書き換わっていないように見える
   • 例えば内部的に計算結果のキャッシュを持つとか、private メンバーが書き換わってる可能性は否定しない
   • いわゆる遅延評価ってのをやろうとするとこっちにならざるを得ない

前者の内部的な immutable はコンパイラーによるチェックで保証もできるけど、後者の見かけ上の immutable はプログラマーの裁量とテストに頼るしかなくて大変。

C++ の const は元来 1. の意味。ただ、メンバー変数に mutable キーワードを付けることで、無理やり 2. の意味の immutable を実現可能。その場合、結局のところほんとに immutable になってるかどうかはプログラマーの裁量に任せられる・・・のであんまり意味があるようにも思えないという欠点あり。

不変なものの使いどころ

C# とかでの class の使い方も種類があって、

1. 普通に OOP 的な意味のクラス、操作の対象
   • GUI の UI 要素とか、ファイルシステムのオブジェクトとか、WCF の Service とか
   • 本質的に mutable なもの（immutable にしても役に立たないもの）も多くて、あんまり immutablity を考える意味なさげ
2. データを表すもの
   • O/R マッパー的に言うところの Entity、WCF 的に言うところの DataContract
   • こっちは、データの不整合防止とか並列処理すること見こすと、極力 immutable の方がよさげ
     • LINQ で使うような型は特に

なので結局、C# に immutable を保証する機能を入れるとするなら、

• Entity 相当のものの immutable を保証する機能を足す
  • 無難なのは、「不変なものの作り方」のところで書いた getter だけが public なプロパティを持ったクラスを生成するような構文糖衣かなぁ
    • メソッドも getter アクセスしかしない
    • C++ の const みたいに普段 mutable な型を immutable に変える機能までは不要なんじゃないかと
    • C# の言語上での保証はできても、IL 上での保証をどうやるか難しそう
  • 見かけ上の immutable は考えない方がよさげ
    • そもそも並列化を見こすということなら、見かけ上の immutable はない方がいいし
    • それにそこを考え出すと、コンパイラーによる静的なチェックだけでは限界があって CodeContract みたいな仕組みとの連携も必要で複雑になるし
• スレッドをまたいで渡していいのはその immutable なオブジェクトだけに限るような仕組みを何か足す
  • Parallel LINQ は 4.0 ですでに入っちゃったんで、これから言語的な保証を足すのはもう難しいかもしれないけども
    • プラクティスとして「Parallel LINQ で使う場合には IEnumerable<T> の T は immutable にしましょうね」というくらいしか
  • Axum みたいなアクター型のタスク並列機能を追加するなら、アクター間の通信には immutable な型しか認めないとか

ってところなのかなぁとか思ったりしています。