【新提案】explicit this parameter

[hax]

当前草案：https://github.com/gilbert/es-explicit-this
目前状态：stage 0

在前次会议上我希望推进这个提案进 stage 1，但是没有成功。失败原因可能有各个方面，其中一点可能是对 motivation 表达得不够清楚。我尝试重新阐述 motivation。

在 glibert 写的原始草案里，主要 motivation 是通过显式命名this来提升代码清晰度，尤其有利于bind operator（或我准备提案的 extensions）。

实际上，我认为，explicit this parameter（和很多提案不一样的是）是多重 motivation 的。

下面列出我认为的 motivations：

Annotation

对 this parameter 进行 annotate 需要显式的 this parameter 语法。

这个方面的 prior art 是 java 的 explicit receiver parameter 和 TS 的 explicit this parameter。

1. type annotation。TS/Flow/Hegel/ClosureCompiler 等都需要对 this 进行类型标注。其中TS/ClosureCompiler已经采用了类似的 this parameter 语法，因此本提案实际上是对这一实践进行标准化，并避免其他工具（flow/Hegel等）发明其他语法，从而产生语法分歧。这是有利于生态的。

2. parameter decorator。显然要 decorate 之，必须得有显式语法。

注意，这个 motivation 并不包含 naming 需求。

标记「方法」

需要标记这其实是一个必须提供receiver的「方法」，而不是普通函数。

这个方面的 prior art 是 c# 的 this modifier（用于标记 extension methods）。

这符合 bind operator（extentions）的需求。（注意这个 glibert 原始草案里的动机不完全一样。）

（关于 extensions/bind op 本身存在的价值，尤其是和 pipeline op 的对比，单独写了一篇，见 #3 ）

同时这个motivation 和 this argument reflection 提案是对称的。this argument reflection 实际上把函数按照意图（到底这个函数被设计为如何使用的）分成了三种，一种是方法（通常以 o.method() 方式使用），一种是普通函数（通常以 f() 方式使用），一种是构造器（通常以 new F() 方式使用）。在语法级别后两者已经有对应的特殊语法（arrow function和constructor），本提案补上了前者。结合这两个提案可以达到更早的报告错误避免误用，extensions 声明应该是绑定真的「方法」——比如使用了 explicit this 的函数。相反，如果错误地提供了 arrow function，那么在声明 extensions 时就可以报告，而不必等到实际调用时。反过来说，使用了 explicit this 的函数以f()或new f()方式使用会立即报错，而不是继续错误的执行逻辑，引起不可知的结果。（注意单纯考虑后一点，本身并不需要 this argument reflection，但是使用 this argument reflection 作为机制可以同时达成两者，且是一个更普适的方式。）

注意，这个 motivation 也不一定需要包含 naming 需求。

解决 this 必然被 shadow 的问题

即对 this parameter 进行显式命名改善编程体验。

这个部分是原始草案里的重点。但在前次会议上也遭到比较多的质疑。我认为这是因为编程体验这个事情是很难完全得到一致意见（比如主张fp的人根本不care this的体验问题甚至倾向于完全否定this因此也否认有任何改进this相关体验的可能），对其作用到底是否能cover其他的成本由于屁股不同而观点迥异（比如引擎工程师恐怕就很难对写业务的JS程序员的体验有共情，但对其所需要的引擎开发成本很敏感；此外我感到委员会里的部分人因为太「聪明」导致很难体会普通程序员的痛点）。

我个人认为可以把这个部分作为 follow-on 提案来绕过争议。

以上。