├── feedback ├── 202303-async-using.md ├── 202303-range-float.md └── 202108-pipeline.md └── README.md /feedback/202303-async-using.md: -------------------------------------------------------------------------------- 1 | # 针对 async explicit resource management 提案语法的投票 2 | 3 | 背景 4 | - https://github.com/tc39/proposal-async-explicit-resource-management/issues/12 5 | - https://1drv.ms/p/s!AjgWTO11Fk-Tkodu1RydtKh2ZVafxA?e=yasS3Y 6 | 7 | ## 选项 8 | - A. `using await x = expr` 9 | - B. `await using x = expr` 10 | - C. `async using x = expr` 11 | 12 | ## 投票结果 13 | - B 14 | - BC 15 | - BC 16 | - C 17 | - BC 18 | - B 19 | - A 20 | - BC 21 | 22 | .|count|percent 23 | ---|---|--- 24 | A | 1 | 12.5% 25 | B | 2 | 25% 26 | C | 1 | 12.5% 27 | BC | 4 | 50% 28 | -------------------------------------------------------------------------------- /feedback/202303-range-float.md: -------------------------------------------------------------------------------- 1 | # range 提案的浮点数问题 2 | 3 | 目前 range 提案支持浮点数，我在 https://github.com/tc39/proposal-Number.range/issues/57 中简要地提到了浮点数的精度问题： 4 | 5 | > it's rare and always have precision-related issue to iterating floats, 6 | > so many programming languages do not support iterating floats in the core lib 7 | 8 | 在上周的 JSCIG 会议上我们再次讨论了这个问题，Jack 认为这是一个值得进一步考虑的问题，建议我单独开个issue。 9 | 10 | 简单说，浮点数总是存在精度问题。 11 | 12 | 比如 `range(0, 10, 3)` 产生 `0, 3, 6, 9`，而 `range(0, 1, 0.3)` 产生 `0, 0.3, 0.6, 0.8999999999999999`。这里存在几个问题： 13 | 14 | 第一，无论采用累加法还是乘法，都可能产生精度丢失。 15 | 16 | 第二，由于精度丢失，导致最后一个值可能正好略小于 end 而被纳入结果。比如 `range(0, 0.9, 0.3)` 得到4个数。 17 | 18 | 第三，精度问题是偶发的，也就是说，很容易产生开发者觉得正确但当参数稍作变化就踩坑的情形。比如`range(100, x, 0.3)`当x是小于166的整数时都没有问题，直到166出现问题。 19 | 20 | 注意，我认为并不能简单地将浮点数精度问题视作开发者教育问题，应该反过来考虑到底在什么情况下用户要使用浮点数，如果没有合理的浮点数的range的用例，也就意味着使用浮点数在实践中几乎总是产生非预期的效果。最终MDN等文档不得不教育开发者避免在range中使用浮点数。另一方面，目前的工具链（如TS或ESLint）并没有足够能力在开发时提示开发者不当引入了浮点数，也就是说在实际工程中我们无法提供保护。与其如此，还不如一开始就不要支持浮点数。 21 | 22 | 另一方面，那么我们是否有足够solid的浮点数的range用例呢？以我个人经验看，似乎是很可疑的。 23 | 24 | 比如在`range(0, 0.9, 0.3)`的例子中，我估计大部分开发者会预期得到`0, 0.3, 0.6`的结果，也就是说，开发者实际想要的并不是浮点数，而是定点数或者decimal。在没有decimal之前，此类用例最合理的方式是写成 `range(0, 9, 3).map(x => x / 10)`。 25 | 26 | 确实可能也有一些用例要使用浮点数且不在意精度，比如绘制图表时，我们在x轴的某个区间取样若干个点，计算这若干个点对应的y值并绘制。但在这样的用例中，更直接的方式是指定区间的取样数量而不是指定step。所以更符合需求的是类似于 [numpy 提供的 linspace 函数](https://numpy.org/doc/stable/reference/generated/numpy.linspace.html)的API。我们当然也可以通过 `range(0, sampleCount).map(i => start + (end - start) * i / sampleCount)` 来达到目标，而此方式中`range`也无需支持浮点数。 27 | 28 | 最后，如果我们不支持浮点数，也可以避免目前草案中针对infinity之类情况做特殊处理，也避免产生safeint范围之外的奇异行为（迭代产生重复的数字）。 29 | 30 | 以上。 31 | -------------------------------------------------------------------------------- /feedback/202108-pipeline.md: -------------------------------------------------------------------------------- 1 | # pipeline 提案讨论 2 | 3 | 由第七次JSCIG会议讨论整理 4 | 5 | - 参与讨论：... 6 | - 整理：@xiaoxiangmoe 7 | - 修订：@hax 8 | 9 | ## hack pipeline operator 10 | 11 | 状态： 12 | 13 | stage 0 14 | 15 | 问题： 16 | 17 | 1. Champions have tentative consensus for Hack-style as the way forward. 【存疑】 18 | 2. Dev community is still split, but there appears to be overwhelming support for pipeline syntax in whatever form we decide on. 【请求出处】 19 | 3. State-ofJS 调查显示，社区希望有 Pipeline Operators（第四希望的特性），但是并不清楚社区对几种 style 的偏好和倾向 20 | 4. 函数链式调用 demo 21 | 22 | ```ts 23 | foo(bar(1, baz(x)[0]).method()); 24 | x |> baz(%)[0] |> bar(1,%).method() |> foo(%) 25 | x |> x => baz(x)[0] |> y => bar(1,y).method() |> z => foo(z) 26 | ``` 27 | 28 | 后面的写法可以提供更详细的有语义的参数名 29 | 30 | 6. async demo 31 | 32 | ```ts 33 | let text = await (await fetch(...)).text(); 34 | let text = await fetch() |> await %.text(); 35 | let text = await (fetch() |> async response => (await response).text()) 36 | ``` 37 | 38 | 7. Static methods & Constructors (conversions) 39 | 40 | ```ts 41 | let x = Object.fromEntries( 42 | Object.entries(x).map(...) 43 | ); 44 | let x = x |> Object.entries(%) |> %.map(...) |> Object.fromEntries(%); 45 | let x = x |> Object.entries |> xs => xs.map(...) |> Object.fromEntries; 46 | ``` 47 | 48 | 简洁程度接近。 49 | 后者大量用于 rxjs，ramda 等库 50 | 51 | 8. 无法复用函数的能力，比如解构，默认值等 52 | 53 | ```ts 54 | const foo = bar |> ({ baz = '', qux = 0 } = {}) => baz.length + qux; 55 | ``` 56 | 57 | 9. 不方便处理嵌套，能力残缺 58 | 59 | ```ts 60 | const foo = x 61 | |> x => (x + z 62 | |> z => Math.min(100,z) 63 | |> z => Math.max(0, z)) 64 | |> x => x + 1 65 | ``` 66 | 67 | 如果用 hack style 那就没法用了 68 | 69 | 10. 现在 hack style 只支持 expression，在 do expression 出来之前，不方便使用循环，if else try catch 等 statement 70 | 71 | 11. 不方便在普通函数的上下文中，插入一个 async 函数上下文 72 | 73 | ```ts 74 | function foo() { 75 | const url = ''; 76 | const requestJob = url |> fetch |> async x => (await response).text(); 77 | addTask(requestJob); 78 | } 79 | ``` 80 | 81 | 12. Vue 2 的 filter 和 Angular 的 pipe 都是 F# style 的。因为它们的影响，社区更习惯 F# style 的 pipeline operator。 Vue 3 把 F# style pipeline operator 当成了 filter 的[替换方案](https://github.com/vuejs/rfcs/blob/master/active-rfcs/0015-remove-filters.md)。 82 | 83 | > There is currently a stage 1 proposal for adding the Pipeline Operator to JavaScript, which provides largely similar syntactical convenience: 84 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # es-discuss 2 | JavaScript语言标准（ECMAScript）中文讨论 3 | 4 | 讨论区：[JSCIG/es-discuss/discussions](https://github.com/JSCIG/es-discuss/discussions) 5 | 6 | ## 在线讨论会 7 | - [第三十一次会议（2025-02-13 周四）](https://github.com/JSCIG/es-discuss/issues/73) 8 | 9 | ## 往期会议 10 | 11 | ### 2021年 12 | - [第一次会议（2021/1/18 星期一）](https://github.com/JSCIG/es-discuss/issues/22) 13 | - [第二次会议（2021/1/22 星期五）](https://github.com/JSCIG/es-discuss/issues/23) 14 | - [第三次会议（2021/3/5 星期五）](https://github.com/JSCIG/es-discuss/issues/26) 15 | - [第四次会议（2021/4/19 星期一）](https://github.com/JSCIG/es-discuss/issues/28) 16 | - [第五次会议（2021/5/14 星期五）](https://github.com/JSCIG/es-discuss/issues/30) 17 | - [第六次会议（2021/7/12 星期一）](https://github.com/JSCIG/es-discuss/issues/31) 18 | - [第七次会议（2021/8/31 星期二）](https://github.com/JSCIG/es-discuss/issues/32) 19 | - [第八次会议（2021/10/25 星期一）](https://github.com/JSCIG/es-discuss/issues/34) 20 | - [第九次会议（2021/11/9 星期二）](https://github.com/JSCIG/es-discuss/issues/35) 21 | - [第十次会议（2021/12/10 星期五）](https://github.com/JSCIG/es-discuss/issues/39) 22 | 23 | ### 2022年 24 | - [第十一次会议（2022/1/21 星期五）](https://github.com/JSCIG/es-discuss/issues/40) 25 | - [第十二次会议（2022/3/11 星期五）](https://github.com/JSCIG/es-discuss/issues/41) 26 | - [第十三次会议（2022/5/31 星期二）](https://github.com/JSCIG/es-discuss/issues/43) 27 | - [第十四次会议（2022-06-16 周四）](https://github.com/JSCIG/es-discuss/issues/45) 28 | - [第十五次会议（2022-07-26 周二）](https://github.com/JSCIG/es-discuss/issues/46) 29 | - [第十六次会议（2022-09-08）](https://github.com/JSCIG/es-discuss/issues/50) 30 | - [第十七次会议（2022-11-29）](https://github.com/JSCIG/es-discuss/issues/52) 31 | 32 | ### 2023年 33 | - [第十八次会议（2023-01-30）](https://github.com/JSCIG/es-discuss/issues/53) 34 | - [第十九次会议（2023-02-01）](https://github.com/JSCIG/es-discuss/issues/54) 35 | - [第二十次会议（2023-03-14 周二）](https://github.com/JSCIG/es-discuss/issues/55) 36 | - [第二十一次会议（2023-03-21 周二）](https://github.com/JSCIG/es-discuss/issues/56) 37 | - [第二十二次会议（2023-05-15 周一）](https://github.com/JSCIG/es-discuss/issues/57) 38 | - [第二十三次会议（2023-07-07 周五）](https://github.com/JSCIG/es-discuss/issues/58) 39 | - [第二十四次会议（2023-09-12 周二）](https://github.com/JSCIG/es-discuss/issues/59) 40 | - [第二十五次会议（2023-09-18 周一）](https://github.com/JSCIG/es-discuss/issues/60) 41 | - [第二十六次会议（2023-11-24 周五）](https://github.com/JSCIG/es-discuss/issues/61) 42 | 43 | ### 2024年 44 | - [第二十七次会议（2024-01-26 周五）](https://github.com/JSCIG/es-discuss/issues/62) 45 | - [第二十八次会议（2024-04-05 周五）](https://github.com/JSCIG/es-discuss/issues/63) 46 | - [第二十九次会议（2024-09-27 周五）](https://github.com/JSCIG/es-discuss/issues/66) 47 | - [第三十次会议（2024-12-04 周三）](https://github.com/JSCIG/es-discuss/issues/72) 48 | --------------------------------------------------------------------------------