为数字字面量添加数字分隔符支持。

Question

只是看到作为Go 1.13的一部分，他们添加了

数字分隔符：现在可以使用下划线（分组）分隔（任何数字字面量的）数字，例如1_000_000，0b_1010_0110或3.1415_9265。下划线可以出现在任何两个数字之间，或者字面量前缀和第一个数字之间。

我觉得这功能非常方便。在编写大数字时，如92347683，在心理上阅读和理解这个数字（是否为百万、十亿等）可能会有困难。为分隔符提供一个语法我认为是读取器的一个很好的补充。不一定是下划线，并且考虑所有有效的Clojure数字时可能需要一些时间。

谢谢

Answer 1

对此有异议的观点是可能会影响代码的搜索。比如说你想在代码中搜索数字10000在何处，你将必须同时搜索10_100，或者可能100_00等。

不确定这是否会成为问题，想不起来上次在我的代码库中搜索数字了，但这仍然是值得考虑的。

Comments

从Java 7开始，这一点确实如此，因为Java 7引入了下划线作为分隔符，我相信是这样的。

https://docs.oracle.com/javase/7/docs/technotes/guides/language/underscores-literals.html

---

反对这样做的类似论点，就是增加原始字符串所提出的内容，这可能也会使工具复杂化，可能只带来小小的好处。任何使解析更困难并且更多边缘情况的内容，基本上都会影响工具。

---

> 这可能会影响到代码的搜索。

与命名空间/关键字语法和命名空间映射相比较。诚然，这将使数字字面值更难grep，但Clojure原本就根本无法被grep。

Answer 2

如果当Clojure阅读器编写时存在这样的功能，我认为我们很可能支持它以达到兼容性。但但现在我认为您必须权衡添加的额外效用好处（我的看法是相当小的）与“更新Clojure工具套件的每个读取器/解析器”的成本，而这肯定是在整个生态系统中的大量工作。

Answer 3

这样做看似是为了让数字更容易被人类解析，因此我认为这更像是一个编辑器的特性，而不是语言本身的特性。

将这种改变加入语言中会使数字的语法更加复杂，使得所有处理工具的工作量翻倍。因此，这会影响编辑器、LSP 服务器、格式化工具、linters 等，而不仅仅是 Clojure reader。

一旦加入，代码库可能会出现多种样式混合的情况，这会增加开发团队和维护人员决定使用哪种数字格式的困惑和挫折。

一些编辑器已经具有显示 lambda 函数和部分使用花哨符号的功能。
许多编辑器也会将十六进制颜色代码着色。
所有这些都不需要改变底层语言。

将此作为编辑器特性的好处是，可以根据需要配置分隔符，例如 _ 或 .，逗号和点对于货币值很有用。

在不改变底层语言的情况下，搜索和使用其他文本工具的能力不受影响。

我宁愿不在语言中包含这个特性，并鼓励那些觉得这个特性有用的人去联系他们使用的编辑工具的维护者。

Comments

> 这样做看似是为了让数字更容易被人类解析，因此我认为这更像是一个编辑器的特性，而不是语言本身的特性。

通过将其推向编辑器，你现在需要完成 Traditionally required work due to the number of editors people will use, in addition to making it inaccessible to reading the code in plaintext (such as in a patch or diff). By adding to the language itself, you completely bypass all of the additional work and provide a consistent and understandable format for all to benefit.

如果我们投票（我知道我们不会），我会投赞成票。

Answer 4

在 Emacs 中，您可以尝试使用此超级模式用颜色突出千位数的块：https://emacs.stackexchange.com/a/59343