Function Arguments Are Not Function Colors: A Distinction in Change Propagation

The Debate on Function Colors

Online discussions frequently conflate function arguments with "function colors." For example, Go's `context.Context` value, which manages timeouts and data, is often cited as an instance where an argument behaves like a color. When a function starts using a context, it is typically threaded through all subsequent called functions, leading to the perception that it forces a change similar to a color.

Distinguishing Arguments from Colors

The article argues that if all function parameters were considered "colors," the concept of function colors would not have emerged decades after programming language functions were invented. There is a distinct characteristic to how concepts like `async` operate in some languages that warrants a specific understanding, separate from general function arguments.

Change Dependency Graph Shape as a Criterion

To differentiate, the article proposes a criterion based on how changes to a function propagate through its call stack. When an attribute of a function, such as a parameter or its `async` status, is modified, the impact on its callers can vary. This impact can be categorized into three cases: no change to any caller, changes only to the direct caller, or changes to all functions in the stack.

Propagation of Changes

The core difference lies in the scope of change propagation. For a typical function parameter, a change might only require modifications to the direct caller. However, for a "function color," a change to a deeply nested function necessitates modifications across the entire call stack, affecting all functions that interact with that specific characteristic. This widespread impact is what defines a true "function color."