撤回不是终点proposal-operator-overloading 的 5 大教训与 JavaScript 运算符重载未来展望【免费下载链接】proposal-operator-overloading项目地址: https://gitcode.com/gh_mirrors/pr/proposal-operator-overloading如果你是一名 JavaScript 开发者可能早就羡慕过 Python 里Decimal(1) Decimal(2)的直观写法——这正是 JavaScript 运算符重载的魅力所在。proposal-operator-overloading 就是一份试图让 JS 支持运算符重载的 TC39 提案它曾经被认真讨论、设计并实现出可运行原型最终却以 Withdrawn撤回收场。但撤回不是终点这份提案留下的设计思考与 5 大教训至今仍在影响着 JavaScript 语言演进的路线图。这份提案想解决什么问题JavaScript 的数值类型长期只有 Number 和后来的 BigInt 两种。做数据计算时向量、矩阵、复数、十进制小数都只能靠方法链比如a.mul(x).add(y)表达又长又绕。这份提案希望让、*、等运算符能被自定义类重载从而支撑更丰富的数值库和领域专用语言DSL。提案给出了四个经典用例Decimal 小数运算、向量/矩阵计算、TensorFlow 式方程 DSL、CSS 单位换算。仓库里还提供了完整原型src/transform 目录下的 Babel 插件 plugin.js配合 src/shim 目录下的运行时 shim.js你甚至可以提前体验这套语法。教训一运算符重载必须克制别让代码变成密码文提案最核心的取舍是只允许重载内置运算符禁止自定义运算符符号。原因很现实JS 已经因为#私有字段和装饰器变得越来越符号密集若再引入自定义运算符可读性将急剧下降。为此设计还刻意制造摩擦必须通过with operators from声明显式启用从机制上防止滥用。教训二可预测性比灵活更重要提案明确拒绝 monkey-patching猴子补丁任何人都不能偷偷改变已有对象上运算符的行为。这保证了旧代码的运算符含义永远不变让新特性不会破坏现有程序。这一点与 Python 的__add__方案形成鲜明对比也成为未来同类提案必须回答的问题——如何让新能力不污染旧代码。教训三类型系统是 JavaScript 绕不开的短板历史上 Decimal 没能进入 ES6正是因为引入它会迫使 JS 面对运算符重载。BigInt 最终选择了单一新类型 内置运算符语义的窄路径而这份提案想走更通用的大路。它在 PROTOSPEC.md 中设计的 Operator Set 分发机制至今仍是研究JS 如何支持更多数值类型的重要参考。教训四性能是提案的生命线提案的设计目标非常明确不用运算符重载的代码性能不能受任何影响使用它的代码也要易于内联缓存inline caching和 JIT 优化。这个零开销抽象的执念正是大型语言特性能否真正落地的关键前提。教训五生态习惯决定成败同样是运算符重载C 和 Haskell 被批评滥用、难读Python 却因 NumPy 被称赞优雅自然。提案特意在 LANGCOMP.md 中横向对比了 Python、Ruby、Swift、Rust 等十余种语言的分发机制结论是决定成败的不是机制本身而是社区能否形成克制的使用习惯。JavaScript 运算符重载的未来展望撤回这份提案并不代表放弃这个方向。现实是BigInt 已进入 Stage 4成为 JavaScript 第一个真正意义上的新数值类型Records Tuples、扩展数值字面量extended numeric literals仍在推进为值类型和3px这类写法铺路一旦值类型Value Types成熟运算符重载很可能会以更稳妥的方式重新回到 TC39 的讨论桌。也许下一次JavaScript 运算符重载会以我们意想不到的优雅姿态归来。而这份被撤回的提案正是那条路上最重要的垫脚石。✅想亲自体验这份历史提案的话可以 clone 仓库 https://gitcode.com/gh_mirrors/pr/proposal-operator-overloading 查看完整源码与文档README.md、PROTOSPEC.md、LANGCOMP.md 都值得细细品读。历史不会消失它会成为未来的养料。【免费下载链接】proposal-operator-overloading项目地址: https://gitcode.com/gh_mirrors/pr/proposal-operator-overloading创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
