LINQのクエリ構文には、範囲変数と呼ばれている機能がある。
たとえば、文字列で与えられた半径と円周を対にしてみる。
string[] values = new string[] { "234.56", "456.78", "345.67", "123.45" };
IEnumerable<Tuple<double, double>> results =
from value in values
select Tuple.Create(double.Parse(value), double.Parse(value) * 2 * Math.PI);
これで正しい結果が得られるのだが、文字列の数値をdoubleにパースする操作は2回行われる。
CLRがとても賢くなったとしたら、double.Parseに副作用が存在しないことをJITで確認して、1回の呼び出しに変換するかもしれないが、あまり期待できない。
そこで、普通ならパースした結果をローカル変数に入れておき、使いまわしたりするのだが、このような目的のために、LINQには「範囲変数」が存在する。
string[] values = new string[] { "234.56", "456.78", "345.67", "123.45" };
IEnumerable<Tuple<double, double>> results =
from value in values
let parsed = double.Parse(value) // 範囲変数parsedに代入
select Tuple.Create(parsed, parsed * 2 * Math.PI);
これなら確実に1回だけパースを行う。その結果を、範囲変数”parsed”に代入し、後で何度でも使いまわす事が出来る。
そういう訳で、このletは実に使い出がある。というより、これが無いとかなり困ったことになる。
ここで、新たな「let」という予約語（厳密には予約語ではないが、ここでは詳しく述べない）が登場するのだが、最初に見たときは「何でvarにしなかったんだ？」と思った。
もはやvarについて知らない人はいないと思うが、
// 右辺から、文字列の配列って分かるよね？
var values = new string[] { "234.56", "456.78", "345.67", "123.45" };
// 右辺から、Tuple<double, double>の列挙子って分かるよね？
var results =
from value in values
let parsed = double.Parse(value)
select Tuple.Create(parsed, parsed * 2 * Math.PI);
というように書き直せる。右辺の結果の型が明確であれば、左辺にわざわざ型名を書かなくても良いでしょうというのが一点。もう一点は連載でもちらりと述べたが、匿名クラスをローカル変数に保持するのに、型名が書けないからという理由だ。
さて、やっとvarについて書けた。以後は注目すべき点がない場合はvarで書く :-)
varの意味づけがイメージ出来るように、実際に匿名クラスを使ってみようか。
var values = new string[] { "234.56", "456.78", "345.67", "123.45" };
// 型名が無いから、書きようがない
var results =
from value in values
let parsed = double.Parse(value)
select new // 匿名クラスだから、型名はない
{
R = parsed,
Length = parsed * 2 * Math.PI
};
上記の「results」は、varでしか宣言出来ない。故にvarという予約語が必要になった訳だ。
で、範囲変数であるletも事情は同じだ。場合によっては、型名が書けない事がある。それならば、letという予約語を作るよりもvarが使えたほうが、覚える予約語が減って良いのではないか？
var values = new string[] { "234.56", "456.78", "345.67", "123.45" };
var results =
from value in values
var parsed = double.Parse(value) // varでいいじゃん？（もちろんNG）
select new
{
R = parsed,
Length = parsed * 2 * Math.PI
};
何故letが導入されたのかは明らかではないが、私が感じた理由を示そうと思う。
まず、上のコードのアウトプットを少し増やす。
var values = new string[] { "234.56", "456.78", "345.67", "123.45" };
var rand = new Random();
var results =
from value in values
let parsed = double.Parse(value)
let randomValue = rand.Next((int)parsed) // 乱数を生成する
select new
{
R = parsed,
Length = parsed * 2 * Math.PI,
Rand = randomValue
};
ちょっと強引な例だが、パースした数値の範囲の乱数を加えた。見ての通り、あらかじめ代入した範囲変数parsedを使って、別の範囲変数を生成することも出来る。この辺りは、通常のローカル変数の感覚と全く変わらない。次のようなコードを書くまでは：
var values = new string[] { "234.56", "456.78", "345.67", "123.45" };
var rand = new Random();
var results =
from value in values
let parsed = double.Parse(value)
let randomValue = rand.Next((int)parsed)
orderby parsed // ちょっとソートしてみようか。
select new
{
R = parsed,
Length = parsed * 2 * Math.PI,
Rand = randomValue
};
私は、上記のselectまで書いたところで、「凍り付いた」。意味が分かるだろうか？
parsedの値で昇順にソートするために、orderbyを書いた。ここまでは良いのだが、その下のselectが一体どうなってしまうのか、非常に不安になった。もちろん、parsedは昇順に並び替えられた順序でやってくる（select句はSelect拡張メソッドに対応している。OrderByの列挙子で順番に値が渡される事を思い出そう）。
では、randomValueはどうなのか？
上のクエリ構文を見ていると、randomValueはorderbyとは関係がないように見える。実際、その下のselect句でrandomValueをそのまま使っている。と言うことは？ソートされるのはparsedの値だけで、randomValueはソートされずに渡されるのか？すると、組み合わせるべき結果がメチャメチャになってしまうのではないか？
（いやいやいや、GetEnumeratorで渡されるというインフラを無視して、ワープしたかのように別のルートで値を渡すなど不可能、不可能なハズだ…？）
もし、let句が無く、varと「書けた」としたら、益々この罠に掛かったことだろう。
翌々書いておく。「ローカル変数」と「範囲変数」は異なるのだ。異なるのだ。異なるのだ。
上記のクエリ構文をメソッド構文に置き換える事が出来るだろうか？ この罠に掛かってからは、メソッド構文のイメージが全く掴めなかった。結局、ILSpyでコードを確認して、以下のように変換されることが分かった。
var values = new string[] { "234.56", "456.78", "345.67", "123.45" };
var rand = new Random();
var results =
values.
Select(delegate(value)
{
var parsed = double.Parse(value);
return new // 不可視の匿名クラス
{
parsed = parsed, // let parsedに対応
randomValue = rand.Next((int)parsed) // let randomValueに対応
};
}).
OrderBy(delegate(entry)
{
return entry.parsed;
}).
Select(delegate(entry)
{
return new
{
R = entry.parsed,
Length = entry.parsed * 2 * Math.PI,
Rand = entry.randomValue
};
});
letのあるべき部分に、上記のような不可視の匿名クラスが作られ、Selectで一旦射影される。つまり、parsedとrandomValueはその時点の値がセットとして扱われる。だから、直後のOrderByでソートされても、parsedとrandomValueが誤った組み合わせになる事は無い。最後のSelectまで、この組み合わせは維持される。
letとletの間にwhereを入れたりした場合でも、新たな不可視の匿名クラスが作られ、Selectで射影される。分離されたletが存在するだけ、匿名クラスが増えることになる。これはつまり、分離されたletが沢山あるほど、匿名クラスの種類が膨れ上がると言う事だ。まあ、それはまだいい（コンパイラが勝手にやっていることだから）が、その度にnewされるというのは気持ちの良いことではない。この匿名クラスの生成とnewはかなりパターン化していると思われるので、ひょっとするとJITは何か工夫するかもしれない。
実際、範囲変数を正しく振る舞わせる為には、上記のようにするしかないだろう。で、メソッド構文が最も正確にLINQを表現できるとしても、上記のようなコードを書くのは面倒だ。やはりletが使えるクエリ構文が手放せない。私はいつも直感で書くのであまり注意していなかったが、自分でパターンを考えてみると、基本はクエリ構文で書き、letが不要な場合にはメソッド構文を選択しているようだ。
しかし、クエリ構文で書くデメリットもある。以前に述べた拡張メソッドとの相性の問題もあるが、クエリに問題があった場合に追跡が面倒だ。メソッド構文で書いていると、適当な場所でパイプラインをぶった切って、ToList()をかますことで、そこに流れたデータを直接デバッガで可視化出来る（データ量が多いとこの方法は使えないが、デバッグ時だから与えるデータを工夫すればいい）。
クエリ構文だと「ぶった切る」事が出来ない。letを使っているとクエリが複雑化しやすい上にこの制限があるのが辛い。
将来のVisual Studioでパイプラインの流れを可視化出来る何かが追加されると、非常に強力なのだが…
#使った事は無いが、Resharperはクエリ構文をリファクタリングで分割出来るようだ。さすがに強力。
