关于 clojure.string/split 移除尾随分隔符的文档

Question

clojure.string/split 和 clojure.string/split-lines 继承了 java.lang.String#split(String,int)函数去除尾随连续分隔符的奇怪默认行为。


(clojure.string/split "banana" #"an")
⇒ ["b" "" "a"]
(clojure.string/split "banana" #"na")
⇒ ["ba"]
(clojure.string/split "nanabanana" #"na")
⇒ ["" "" "ba"]


在 split-lines 的情况下，逐行处理文件并重新组合会导致删除文件中尾随的新行。在两种情况下，此行为都很令人惊讶，并且无法从文档字符串中推断出来。split的解决方案是通过传递一个-1限制。

*建议:* 考虑到当前用户可能依赖于当前行为，附件仅更新文档字符串来警告此行为，并建议使用-1作为限制来解决。

*补丁:* clj-1360-2.patch

Answer 1

评论者：jafingerhut

鉴于一些人可能在实际测试、部署等之后依赖于当前行为，因此我在此记录可能会有所帮助，而不是在此处更改行为。

我目前没有修改后的文档字符串的建议，但请注意，在这个链接中有关于此行为的例子，以及如何可以使用额外的“-1”限制参数从末尾获取所有拆分的字符串：

Answer 2

评论由：retrogradeorbit

这个bug刚咬了我一口。+1 修复。如果我们只是记录下当前的行为，那么我们会得到一个令人惊讶且不一致的分割行为（为什么保留内部空值，但删除外部值？）这与你使用过的任何其他分割方式都不同。可选的 -1 限制参数看起来非常繁琐，但如果修复可以保持 -1 参数的工作状态。

编辑：这看起来与Java的String类的行为相同：http://stackoverflow.com/questions/2170557/split-method-of-string-class-does-not-include-trailing-empty-strings
希望在这种情况下那个clojure.string/split调用中limit默认为-1。

Answer 3

评论由：stu

这真的太糟糕了，原始开发者被打到了脖子上。(Ow.)

我讨厌Java泄露，但考虑到这已经存在了，而且人们很可能已经在依赖默认和负参数行为，我想最坏的情况是准确记录我们现在的语义。

Answer 4

评论由：alexmiller

将CLJ-1857的更改合并到clj-1360-2.patch中。

Answer 5

参考：[https://clojure.atlassian.net/browse/CLJ-1360](https://clojure.atlassian.net/browse/CLJ-1360)(由timmc报告)