achun/proposal-static-type-constraints-features

请求支持

Closed this issue · 7 comments

achun commented

@syg 非常冒昧的呼叫您

因为的我英文水平还达不到与人交流的水平, 我在 tc39 成员列表中找到您, 猜测您应该是会中文的,
请求您的支持.

这个提案通过巧妙的使用 void 给 ECMAScript 提供了静态类型约束能力, 而且应该是无副作用的,
向前向后都兼容的.

ps: 而且它的形式虽然很多, 但竟然没有二义性. 我甚至不能把所有的形式全都列举出来.

希望听到您的意见, 并得到您的支持.

另外我已经签署了非 tc39 成员贡献者需要签署的文件.

这个提案貌似过不了,也有类似的提案不过都没有动静了…给语言本身添加不是很好的方式,动态特性能编码更灵活,如果需要静态类型,TypeScript不很好么

achun commented

@islishude 以前的提案都是增加新语法, 这次的没有新语法, 只是语义上的, 重要的是该方案与以前的代码无冲突, 就像当年的 asm.js 一样.
TS 的问题我们就不讨论了, 毕竟那是另外一种语言, 我们讨论和关系的是 ECMAScript 本身.

退一步, 就算 TC39 因为某种原因拒绝了该提案, 我依然可以在现实中使用, 毕竟它是无冲突, 全兼容老代码的, 我坚持这么用是有原因的, 具体就不细说了, 很繁杂的.
毕竟设计出这么多种语言就是满足不同需求的, 存在即合理, 都有各自的需求场景.

一个很有趣的想法!但是它在现在的 ES 中都是合法的,并没有新增语法/API,为什么要提交到 TC39呢?

achun commented

@aladdin-add
如果能通过的话, 应该会出台相关的规范, 比如:

  1. 强制进行类型约束检查
  2. 提供开关,
  3. 提供反射机制, 让使用者有机会在运行时获取到类型约束的相关信息.

总之, 不会只是通过了, 然后什么配套设施都没有出台吧!!!

只要有任何配套设施出台, 严格类型检查就会方便很多.

ps: 配套设施是怎样的, 我还真提不出来, 毕竟涉及内部算法, 无法在不了解的情况下提出配套提案.

syg commented
achun commented

@syg
See https://esdiscuss.org/topic/proposal-static-type-constraints-features

是的, 我真的需要翻译, 防止我糟糕的英文水平产生歧义.

achun commented

依据 tc39 成员总数和参与该提案讨论的情况, 我感无法获得拥护者了.
所以, 这个提案将变成我个人的使用方法.
还好, 我可以只考虑自己的习惯和需求进行设计了.