博士

やあ、ロボ子。ISO C標準メーリングリストでラムダ式に関する議論が始まったみたいじゃぞ。

ロボ子

ラムダ式ですか、博士。C言語に新しい風が吹くのでしょうか？

博士

そうじゃな。Jens GustedtさんがC標準に適切な関数とデータ型を導入する提案を進めているらしいぞ。これは見逃せないのじゃ。

ロボ子

なるほど。現在のC言語で関数とデータを扱う場合、APIの調整が必要になることが多いですよね。コールバック関数を使うために、構造体を作ってデータをコピーして、関数にポインタとして渡す、と。

博士

その通り！非同期APIだと、操作のライフタイムが関数を超える場合にヒープにデータを配置する必要があるからの。面倒じゃな。

ロボ子

GCCのネストされた関数という非標準拡張機能もありますね。関数の中で関数を定義できるという。

博士

そうじゃ、ロボ子。でも、セキュリティ上の問題で使用が禁止されている環境も多いのじゃ。GCCはネストされた関数を関数ポインタとして機能させるために「trampolining」という手法を使うからの。NXビットをオフにする必要があって、セキュリティリスクを高めることになるんじゃ。

ロボ子

マルチスレッド環境ではデータ競合が発生する可能性もありますし、ABIの互換性の問題もあるんですね。

博士

ClangのBlocksは、GCCのネストされた関数に対する別のアプローチじゃ。Blockは実行するステートメントのシーケンスで、コンパイラが最適な場所に配置するのじゃ。

ロボ子

Blocksは関数ポインタに変換できないんですね。`void*`パラメータを使用する必要があると。

博士

そうじゃな。そして、いよいよラムダ式じゃ！構文は`[ captures... ] ( args... ) { statements... }`じゃ。

ロボ子

変数は手動でキャプチャする必要があるんですね。明示的なキャプチャとデフォルトでの値によるキャプチャで、データ競合を回避する、と。

博士

その通り！Function Literals（キャプチャを持たないラムダ）は、通常のC関数ポインタに変換できるんじゃ。

ロボ子

ラムダ式は、複数のプラットフォームやコンパイラの組み合わせで動作するようにすべき、という結論ですね。

博士

そうじゃ。開発者の選択を尊重し、詳細がエコシステムの基本的な部分となり、変更が不可能になることを防ぐべきじゃ。Cの「魔法」は、言語の複雑さよりも危険じゃからの。予測可能なルールを適用すべきじゃ。

ロボ子

コンパイラの推測に頼るべきではない、と。勉強になります。

博士

ところでロボ子、ラムダ式を使って、私がお風呂で歌うアヒル隊長の数を数えるプログラムを作ってみないか？

ロボ子

博士、アヒル隊長は数えるものではなく、愛でるものですよ。