関数の色に関する議論では、関数の引数が色になり得ると主張する人もおり、例としてGoのcontext値を挙げています。contextはタイムアウトとキャンセルを管理し、直接使用されなくても関数を通じて渡されるように設計されています。関数がcontextを使用すると、呼び出されるすべての関数にそれを渡す必要があり、表面的には色のように見えます。

しかし、すべてのパラメータが色であるなら、その概念は関数の50年以上後に発明されることはなかったでしょう。asyncには捉える価値のある明確な性質があります。明確にするために、変更依存グラフを考えてみましょう：呼び出しスタックの深いところで関数属性を変更すると、呼び出し元に3つの方法で影響を与える可能性があります：呼び出し元の変更なし、直接の呼び出し元の変更、またはスタック内のすべての関数の変更。

色は上にあるすべての関数に反応を強制しますが、通常の変更は呼び出し元にのみ伝播し、捕捉できます。実際には、関数はチェーンを断ち切り、上位の関数を下位の変更から隔離します。構造化プログラミングは変更を隔離するために存在し、すべてのパラメータ変更がスタック全体に変更を強制するなら、管理不能になるでしょう。