支持数字分隔符的数字字面量。

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

---

反对这种做法的一个相似论点是，与添加原始字符串类似，这可能会使得工具复杂化，也许好处并不大。任何使解析更加困难，并且具有更多边缘情况的工具都会受到影响。

---

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

告诉它关于命名空间/关键字语法和命名空间映射。确实，这使得数字字面量更容易高亮显示，但Clojure本身就不是很容易被高亮显示。

Answer 2

如果Clojure读者编写时存在这种情况，我认为我们很可能会支持它以实现一致性。但是现在我认为你必须权衡追加的实用性效益（在我看来相当小）与“更新所有Clojure工具的每个读者/解析器”之间的利弊，并且在整个生态系统中这肯定是一份大量工作。

Answer 3

这个理由似乎是让数字更易于人类解析，所以我觉得这更像是编辑器中的一个特性，而不是语言本身。

将此类更改添加到语言会使数字的语法更复杂，使得所有工具处理正确的倍数工作量增加。所以这会影响到编辑器、LSP 服务器、格式工具、linters 等。所以这不是限于 Clojure 读取器的更改。

一旦添加，代码库很容易成为一种风格的混合，增加了混乱和挫败感，要求开发团队和维护人员决定使用哪种数字格式。

已经有编辑器功能可以显示带有花哨符号的 lambda 函数和部分。
许多编辑器也会为十六进制颜色代码着色。
所有这些都无需更改底层语言。

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

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

我宁愿不在语言中包含此功能，并鼓励那些认为它有用的人与它们使用的编辑工具的维护者取得联系。

Comments

> 似乎是为了让数字更容易让人类解析，所以我觉得这更像是编辑器中的一个功能，而不是语言。

通过将其推向编辑器，现在你需要做两倍的工作，因为人们会使用多少个编辑器；除了使以明文方式（如补丁或 diff）读取代码不可访问之外。通过添加到语言本身，你可以完全绕过所有额外的工作，并提供一个一致且易于理解的格式，供所有人受益。

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

Answer 4

在Emacs中，您可以使用该模式来突出显示成千上万的代码块并使用颜色：https://emacs.stackexchange.com/a/59343