函数参数为何不是函数颜色
Function Arguments Are Not Function Colors
网上常有人争论，像 Go 语言中的 context.Context 这样的参数是否也算作函数的“颜色”。作者认为，真正的“颜色”意味着底层函数的任何属性变更，都会强制性地、不可逃避地波及整个调用栈上的所有上层函数。而普通参数变更通常能被中间层封装，不会一路传导至顶层。文章通过对比依赖图形状，指出颜色变更具有非局部性，打破了结构化编程的封装优势。以 Haskell 的 STM 为例，展示了部分颜色如何强制约束中间函数。理解这一区别，有助于我们更清晰地认识语言特性，避免将普通参数传递误判为颜色机制。
颜色变更的本质在于，它必须跨越中间的调用层级，强制将变更施加于相关颜色岛内的所有其他函数。
HN 评论区
19- skavi
在这个框架下，Rust 的 async fn 不会被着色，因为调用栈中的任何函数都可能在执行器上阻塞。如果你把“spawn point”也算作调用栈的一部分，那么许多其他语言的情况也类似。
这种区分感觉没什么用，但我认为“函数着色”这个框架本身就没多大用处。
- legobmw99
我觉得这种区分是合理的，不过值得指出的是，正如作者所述，函数参数_确实可以_是颜色，前提是这些参数必须来自特定位置。例如，在某些语言中，只有 `main` 函数能接收与系统功能相关的特定参数，或者在能力框架（capability framework）中，只有顶层函数能接收能力令牌。
- smilekzs
我的个人衡量标准：
一个概念上的增量变更，对应的是比例相当的代码 diff，还是令人惊讶的彻底重构？
代码模式是否自然地为逐步调整或重组事物提供了足够的空间？
当这些问题的答案不尽如人意时，我往往会发现“着色”对框架、库或语言（有时是全部）产生的影响。