Why Function Arguments Are Not Function Colors

Several online debates have questioned if function arguments could also be considered colors. For example, in Go, context.Context is introduced to manage timeouts, cancellation and a small amount of data that can be threaded through various functions. In practice, once a function starts using a context, it should be passed down to all called functions that could potentially utilize it.

This superficially resembles the idea of a color, as changing the context value means all downstream functions must also adapt. However, this analogy breaks down when considering that in reality, functions typically prevent the change from propagating all the way up to the top of the call stack. Programmers utilize structured programming to encapsulate changes and isolate higher functions from lower functions' details.

Thus, while a "color" change would require all functions above to adapt, a normal change can be encapsulated, requiring only direct callers to adjust. The key distinction is that a "color" change would necessitate all functions in the call stack to conform, while a normal change only propagates to the immediate caller. The concept of "colors" is rarely necessary in practice, as most changes can be contained within their immediate context.